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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document describes the II interface between IMS Centralized Services (ICS) UE and Service Centralization 
and Continuity (SCC) Application Server (AS). 

This specification defines a new application layer protocol over II interface, specifies the interaction between the ICS 
UE and the SCC AS including session control procedures and supplementary services control procedures. 

The protocol is intended to be independent of the transport protocol used so it can be applied to a number of 
technologies that need different transport protocols. 

The overall ICS architecture is specified in 3GPP TS 23.292 [2]. 

The procedures for delivery of IMS Service Continuity that do not use the II protocol are specified in the document 

3GPPTS 24.237 [13]. 

The present document is applicable to User Equipment (UE) and Application Servers (AS) which are intended to 
support the IMS centralized services. 
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[12] 3GPP TS 24.229: "IP multimedia call control protocol based on Session Initiation Protocol (SIP) 

and Session Description Protocol (SDP); Stage 3". 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 
3GPP TR 21.905 [1]. 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.292 [2] apply: 

ICSUE 

sec AS 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.237 [7] apply 

Access Transfer 

Service Control Signalling Path 

Session Transfer Identifier (STI) 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 24.292 [5] apply: 

PSIDN 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 24.229 [12] apply: 

default public user identity 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
3GPPTR 21.905 [1]. 

ICS IMS CentraHzed Services 

sec AS Service Centralization and Continuity Application Server 

STI Session Transfer Identifier 

USSD Unstructured Supplementary Service Data 



General description 



4.1 General 

For the current version of the specification the application layer protocol is run over Unstructured Supplementary 
Service Data (USSD) transport as defined in 3GPP TS 24.090 [4], however the application layer protocol is not 
restricted to USSD transport. 
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4.2 Structure of the protocol 

4.2.1 Introduction 

The II protocol is a message based point to point protocol. The II protocol messages are transported within a point-to- 
point transport layer connection protocol and are exchanged between the ICS UE and SCC AS. 

The II protocol is a transport-independent protocol, i.e. the II session control entities can exchange the II protocol 
messages over any transport-layer connection that connects the ICS UE and the SCC AS. 

The Ilprotocol's notation maintains a format of two parts, i.e. II message common part and II information elements. 
The II message common part is included in every II message. The II information elements those are included in an II 
message depend on a type of II message being sent. 

4.2.2 Application level protocol 

Overall descriptions with application level protocol are specified as following: 

1) it is used to access IMS services (e.g., IMS session origination); 

2) it is a point to point protocol between the ICS UE and the SCC AS; 

3) its protocol does not support authentication; 

4) it does not support segmentation of messages; 

5) its messages are self-identifying; and 

6) it runs over any point-to-point transport-layer connection (e.g. USSD). 

4.2.3 Transport level protocols 

4.2.3.1 General 

The transport-layer connection that is used to transfer the II protocol messages is a bi-directional point-to-point 
connection between the ICS UE and the SCC AS. This transport-layer connection is a symmetric connection, i.e. the 
source-point on the transport-layer connection that is used to send the II protocol messages is also a destination-point 
for the incoming II protocol messages. 

4.2.3.2 USSD as transport level protocol 

The USSD provides a point-to-point transport layer connection between the II protocol entities. The USSD supports a 
two-way alternative interactive communication (i.e. semi-duplex communication). At any given time, only one II 
protocol entity (either the ICS UE or the SCC AS) with its turn may send the II messages, while at the same time its 
peer is permitted only to receive the II messages. If the receiving II protocol entity (either the ICS UE or the SCC AS) 
wants to send an II message to its peer, it has to buffer the II message until it has its turn. 

When the USSD is used as the transport layer connection, overall descriptions are specified as following: 

1) the II messages shall be buffered until the USSD layer (in the ICS UE or CS network) gets its turn to send the 
buffered messages over the USSD connection; 

2) if the USSD connection is still in maintenance and the USSD layer (in the ICS UE or CS network) hasn"t sent an 
II message for a specific time, an II -Dummy message shall be delivered to the peer to transfer the turn with the 
consideration of not delaying the transmission of the Ilmessage; and 

3) if the II session is established, the USSD connection will be released. 
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5 Functional entities 

5.1 User Equipment (UE) 

To be compliant with this specification, a UE shall implement the role of ICS UE capabilities defined in 
subclauses 6.2.1.2, 6.2.3.2,6.2.4.2,6.2.5.2.1, 7.5.3.2.1.1, and 7.5.3.2.2.1 

5.2 Application Server (AS) 

To be compliant with this specification, a AS shall implement the role of SCC AS capabilities defined in 
subclauses 6.2.1.3, 6.2.3.3, 6.2.4.3, 6.2.5.2.2, 7.5.3.2.1.2, and 7.5.3.2.2.2. 



6 Communication between ICS UE and SCC AS via 11 

interface 

6.1 Introduction 

The ICS UE and SCC AS use the II interface to setup, control, maintain and release an II session control channel and 
associated media over the CS bearer. 

If an ICS US capable of using the II interface registers with the IM CN Subsystem (IMS), it shall associated keys with 
public user identities in the format of a SIP URI in accordance with annex A. A public user identity can be derived if a 
key is associated with the public user identity. 



6.2 Session control procedures 
6.2.1 Session setup 



6.2.1.1 General 

The ICS UE setups the II session with CS media and the service control signalling via the II reference point. II is used 
to control services in the IM CN subsystem. 

The II sessions can only be created by II session setup messages. The II Invite message is an II session setup message. 
The II sessions can be torn down by II session release messages. The II Bye message is an II session release message. 

The following subclauses describe the procedures of the ICS UE and the SCC AS for II session setup: 

subclause 6.2.1.2.1 describes the procedures of ICS UE II session origination; 

subclause 6.2.1.2.2 describes the procedures of ICS UE II session termination without UE assisted T-ADS 
function; 

subclause 6.2.1.2.3 describes the procedures of ICS UE II session termination with UE assisted T-ADS 
function; 

subclause 6.2.1.3.1 describes the procedures of SCC AS II session origination; 

subclause 6.2.1.3.2 describes the procedures of SCC AS II session termination without UE assisted T-ADS 
function; and 

subclause 6.2.1.3.3 describes the procedures of SCC AS Ilsession termination with UE assisted T-ADS 
function. 
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6.2.1 .2 Detailed behaviour of ICS UE 

6.2.1 .2.1 ICS UE CS Session Origination 

6.2.1.2.1.1 General 

The following subclauses describe the procedures at the ICS UE for session origination. 

6.2.1 .2.1 .2 Sending an II Invite 

When the ICS UE originates an II session using the Ilreference point, the UE shall: 
1) generate an II Invite message that includes: 

a) a Message Type Value and a Reason Value set to indicate the message is a Mobile Originated II Invite 
message, accordance with table 7.3.1; 

b) a new value in the Call-Identifier (Part-1) IE, as specified in subclause 7.2.2.1.4. The Call-Identifier will 
uniquely identify this II session between the ICS UE and the SCC AS; 

c) an allocated Message sequence number; 

d) a From information element that 

if the UE has previously SIP registered and the public user identity is to be a SIP URI and the public user 
identity can be derived (see annex A) then: 

i) if the public identity indicates the default public user identity, the Identity Information IE (see 

table 7.3.2.2) Code Specific Information element is set to "Unspecified" (see table 7.4.2.3.1-2) and the 
length IE is set to 0; 

ii) if the public identity is not the default public user identity and the public user identity indicated can be 
derived (see annex A), the Identity Information IE (see table 7.3.2.2) Code Specific Information 
element is set to "Identifier" (see table 7.4.2.3.1-2) and the length IE is set to 4. 

otherwise Identity Information IE (see table 7.3.2.2) Code Specific Information element set to: 

i) a "SIP URI" (see table 7.4.2.3.1-2) if the public user identity is a SIP URI and the Information body 
(see table 7.3.2.2) containing the SIP URI; 

ii) an "International number" (see table 7.4.2.3.1-2), if the public user identity is a Tel URI or SIP URI 
with URI parameter user=phone and the Information body (see table 7.3.2.2) containing the digit 
string contained in the URI. 

e) a To information element that includes either a SIP URI or an E. 164 number, and will be used by the SCC 
AS to determine the identity of the called user; 

f) a Privacy information element that indicates the ICS UE's privacy preferences. The SCC AS will apply these 
preferences to the SIP session that the SCC AS will establish on behalf of the UE; 

g) a CS access network type indicator; 

h) optionally include any feature tags in the: 

i) Accept-Contact IE , as specified in subclause 7.3.2.5 if the parameter tag "explicit" or "require" as 
specified in RFC 3841 [14] are not required; 

ii) ERAccept Contact IE, as specified in subclause 7.3.2.6 if the parameter tag "explicit" or "require" as 
specified in RFC 3841 [14] are required; and 

iii) Reject Contact IE as specified in subclause 7.3.2.7; and 

i) a Timestamp information element that includes current local time measured in seconds. The element will be 
used by the SCC AS to determine the staleness of the message. 
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2) select the transport layer protocol depending on the access network type, and forward the II Invite message 
toward the SCC AS. 

6.2.1 .2.1 .3 Receipt II Progress Call Progressing 

When the UE receives an II Progress message with Progress reason set to Call progressing, the UE shall: 

1) save the received Call-Identifier value and use it for further reference to this session; 

2) verify if the message is in sequence according to the Message sequence number value, and save the received 
Message sequence number; 

3) store the SCC AS PSI DN value (i.e. the E.164 number) received in the SCC-AS-id information element; and 

4) store the STI value (i.e. the E.164 number) if received in the Session-identifier information element. 

NOTE 1: The STI value uniquely identifies the II session being established, and it may be subsequently used to 

refer to this II session, e.g. the SCC AS uses the STI to correlate the access transfer request received via 
the PS access with the active session established via the II interface. 

NOTE 2: The UE may indicate the Progress reason value to the user. 

Editor" s note: Responses indicating an error are FFS. 

Upon receiving the SCC AS PSI DN (i.e. the E.164 number) conveyed in the II Progress message with Progress reason 
set to Call progressing from the SCC AS, the ICS UE shall initiates the call over the CS domain by sending a SETUP 
message to the MSC Server as specified in 3GPP TS 24.008 [3] as follows: 

1) the Called Party BCD Number information element is set to the SCC AS PSI DN (i.e. the E. 164 number) 
received in the II Progress message with Progress reason set to Call progressing; 

2) Type Of Number is set to "International" and Numbering Plan Indicator set to "E.164". in the Called Party BCD 
Number information element; and 

3) the Calling Party Number information element is set to the E.164 number) included in the To-id information 
element of the initial II Invite message in accordance with subclause 6.2.1.2.1.2 step e) 

Editor's note: It is FFS if the ICS UE uses the Calling Party Number IE because the MSISDN is asserted by the 

MSC. If the use of the Calling Party Number IE is allowed only if an E. 164 number was received in the 
To-id information element then this needs to be qualified. 

6.2.1.2.1.4 Receipt II Progress reason set to 1 80 

When the ICE UE received an II Progress with Progress reason set to 180 the UE shall: 
1) provide an alerting indication to the user. 

6.2.1 .2.1 .5 Receipt II Success 

When the ICS UE receives an II Success message, the UE shall: 

1) verify if a II session exists for the received Call-Identifier value; 

2) verify if a the message is in sequence according to the Message sequence number value; 

2A) verify that a CONNECT message as specified in 3GPP TS 24.008 [3] has been received in response to the 
SETUP message that was sent containing the SCC AS PSI DN; and 

3) consider the II session to be established, if verification was successful. 
Editor" s note: Responses indicating an error are FFS. 
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6.2.1 .2.2 ICS UE CS Session Termination without UE assisted T-ADS 

If the ICS UE receives an II Invite message from the SCC AS, and the UE determines that no II session exists for the 
received Call-Identifier value, the ICS UE shall: 

0) retrieve the SCC AS local time value from the Timestamp information element of the II Invite message, and 
validate the staleness of the message by applying the following equation: 

SCC_AS_time_in_the_Il_Invite_message - SCC_AS_time as specified in subclause 6.4.1 item 5) 

>= 

(ICS_UE_local_time - ICS_UE_time as specified in subclause 6.4.3.1 item l)e) - Deviation 

NOTE: Deviation parameter is 64*T1 seconds. 

If the equation is true the message is not stale and it shall processed by the following sections. Otherwise, the 
messages is discarded and no response is generated to the II Invite message; and 

1) store the information contained in the II Invite message, including the called party identity included in the To- 
header value , the calling user's public user identity included in the From header value , the SCC AS PSI DN 
(i.e., the E.164 number) included in the SCC-AS-id information element, the Message sequence number, the 
Call-Identifier (Part-2) subfield, the STI value (i.e. the E.164 number) if received in the Session-identifier 
information element, Accept-Contact information element, ERAccept-Contact information element and Reject- 
Contact information element and transport layer information identifying the transport connection over which the 
II Invite message was received; and 

1 A) if the To information element in the II Invite message contains a: 

i) Code Specific Information element set to "Unspecified" (see table 7.4.2.3.1) and a length IE set to then the 
Public user identity shall be set to the default public user identity. 

ii) Code Specific Information element set to "Identifier" (see table 7.4.2.3.1-2) and a length IE set to 4, then the 
public user identity can be derived (see Annex A) and shall be set to the identifier value received in the 
information element body of the To IE. 

iii) Code Specific Information element set to "International number" (see table 7.4.2.3.1-2) or "SIP URI" (see 
table 7.4.2.3.1-2), then the public user identity of the UE shall be set to the Identity in the Information 
element body of the To IE. 

NOTE 1 : The UE may indicate the public user identity used to address the UE in the incoming session to the user. 

2) initiate a call over CS bearer by sending a SETUP message to the MSC Server as specified in 
3GPP TS 24.008 [3] as follows: 

i) the Called Party BCD Number information element is set to the received SCC AS PSI DN (i.e., the E.164 
number) received in the II Invite message 

ii) Type Of Number set to "International" and Numbering Plan Indicator set to "E.164" .in the Called Party BCD 
Number information element. 

NOTE 2: When the ICS UE receives an II Invite message, the UE may send an II Progress message with Reason 
set to Call progressing. The II Progress message with Reason set to Call progressing is identical to the II 
Progress message with Reason set to Ringing described below, except the Reason subfield will be set to 
Call progressing. 

Editor" s note: Responses indicating an error are FES. 

When the ICS UE receives an indication from the CS domain that the media resources are available (i.e. the UE 
receives a ALERTING message as specified in 3GPP TS 24.008 [3]) the UE shall: 

1) generate an II Progress message with Progress reason set to Ringing containing the following information: 

a) a Message type Value and a Reason Value set to that indicate the message is an II Progres message, 
accordance with table 7.3.1; 
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b) a new value in the Call-Identifier (Part-1) subfield, as specified in subclause 7.2.2. The resulting Call- 
Identifier uniquely identifies this II session between the UE and SCC AS; 

NOTE 3: A new value in the Call-Identifier (Part-1) subfield is inserted only if this is the first II message sent to 
the SCC AS. Otherwise the previously set Call-Identifier value is used. 

c) increment the stored Message sequence value, store it, and include it in the Message sequence subfield; 

d) set the Reason subfield (per figure 7.3.1) to 183; and 

2) send the II Progress message with Progress reason set to Ringing towards the SCC AS over the transport layer 
connection over which the II Invite message was received. 

If the user accepts the request, the ICS UE shall: 

1) generate an II Success message containing the following information: 

a) a Message Type Value and a Reason Value set to indicate the message is an II Success message, accordance 
with table 7.3.1; 

b) the stored Call-Identifier value that uniquely identifies this II session between the UE and SCC AS; 

c) increment the stored Message sequence value, store it, and include it in the Message sequence subfield; and 
Editor's Note: include a B-Party URJ header value set to a SIP or tel URI is FFS. 

2) send the II Success message towards the SCC AS over the transport layer connection over which the II Invite 
message was received. 

6.2.1 .2.3 ICS UE CS Session Termination with UE assisted T-ADS 

If the ICS UE receives an II Invite (Augmentation) message with a Replaces header field and it is determined that there 
is a SIP session being established for the Replaces header value (e.g., the Replaces header is set to a value identical to 
(or deduced from) the SIP session identifier in a previously received SIP INVITE), the ICS UE: 

1) shall interpret it as session control fallback from Gm to II; and 

2) shall use the Replaces header value to correlate the II Invite message with the SIP INVITE request prevously 
received, to get SCC AS PSI DN, the called party identity and the calling party identity. 

3) shall indicate that the public user identity, the To header value, and the SCC AS PSI DN are in the correlated SIP 
INVITE request, by setting the Identity Information IE (see table 7.3.2.2) Code Specific Information element to 
"Unspecified" (see table 7.4.2.3.1) and the length IE is set to 1 and octet 3 is set to all "0"s, respectively. 

NOTE: In this case, some headers (e.g. Privacy header) can be omitted from the II Invite message, for the 
information can be get by the ICS UE from the correlated SIP INVITE request. 

Afterwards, the ICS UE shall behave as specified in subclause 6.2.1.2.2. 

6.2.1.2.4 Failure 

The ICS UE may receive an II Failure message at any time. If the ICS UE receives an II Failure message, the ICS UE 
shall: 

1) save the received Call-Identifier value and use it for further reference to this session; 

2) verify if the message is in sequence according to the Message sequence number value, and save the received 
Message sequence number; 

3) extract the Reason Value as defined in subclause 7.2.2.1.3 from the message; and 

4) act in accordance with corresponding equivalent status code value as defined in subclauses 21.3 to 21.6 of 
RFC 3261 [6]. 

5) release the session as defined in subclause 6.2.3 
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6.2.1 .3 Detailed behaviour of SCC AS 

6.2.1 .3.1 SCC AS CS Session Origination 

6.2.1.3.1.1 General 

The following subclauses describe the procedures at the SCC AS for II session origination. In this scenario, the SCC 
AS serves the originating user. 

6.2.1.3.1.2 Receipt II message 

Upon receiving an initial II Invite message from the ICS UE via the II reference point, the SCC AS shall: 

0) retrieve the ICS UE local time value from the Timestamp information element of the II Invite message, and 
validate the staleness of the message by applying the following equation: 

ICS_UE_time_in_the_Il_Invite_message - ICS_UE_time_ as specified in subclause 6.4.4.1 item 1) 

>= 

(SCC_AS_local_time - SCC_AS_time_ as specified in subclause 6.4.4.1 item 3)d) - Deviation 

NOTE: Deviation parameter is 64*T1 seconds. 

If the equation is true the message is not stale and it shall processed by the following sections. Otherwise, the 
messages is discarded and no response is generated to the II Invite message; and 

1) store the information received in the II Invite message, including the called party identity included in the To 
header value. From header value, the requested privacy type included in the Privacy information element, the 
Sequence-ID header value, Accept-Contact information element, ERAccept-Contact information element and 
Reject-Contact information element, Call-Identifier (Part-1) subfield (as specified in subclause 7.2.2.1.4), and 
transport layer information identifying the transport connection over which the II Invite message was received; 
against the IMS private identity of the originating user's UE. The IMS private identity to store the information 
against is determined by comparing the C-MSISDN associated with the IMS private identity against the: 

i) MAP service ISDN-Address-String as specificed in 3GPP TS 29.002 [14] if USSD is used as the transport 
protocol for the message, 

ii) MAP Forward Short Message sm-RP-OA as specificed in 3GPP TS 29.002 [14] information element if SMS 
is used as the transport protocol for the message. 

lA) dynamically allocate a STI and bind it to the information stored in step 1. The STI is specified as an E.164 
number; 

NOTE 1: The STI value uniquely identifies the II session being established, and it may be subsequently used to 

refer to this II session, e.g. the SCC AS uses the STI to correlate the access transfer request received via 
the PS access with the active session established via the II interface. 

IB) If the From Information element in the II Invite message is 

i) included and the Code Specific information element is set to "Unspecified" (see table 7.4.2.3.1-2) and the 
length IE is set to the default public user identity shall be stored against the II Invite. 

ii) included and the Code Specific information element is set to "Identifier" (see table 7.4.2.3.1-2) and the length 
IE is set to 1, the received identifier as derived in Annex A shall be stored against the II Invite. 

iii) included and the Code Specific information element is set to set to "International number" or "SIP URI" the 
Identity contained in the information element body of the To header value shall be stored against the II 
Invite. 

2) Void 
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6.2.1 .3.1 .3 Sending an II Progress message in response to II Invite message 
The sec AS shall: 

1) generate an II Progress message containing the following information: 

a) a Message Type Value and a Reason Value set to indicate the message is an II Progress message, accordance 
with table 7.3.1; 

b) a Call-Identifier field, that was constructed by appending the allocated Call-Identifier (Part-2) subfield to the 
stored Call-Identifier (Part-1) subfield, as specified in subclause 7.2.2.1.4. The Call-Identifier value uniquely 
identifies this II session between the ICS UE and SCC AS; 

c) add one to the stored Sequence-ID header value. Store and include the Sequence-ID header value; 

d) include the allocated SCC AS PSI DN (i.e., the E.164 number) in the SCC-AS-id information element; e) set 
the Reason field to 183 (per figure 7.3.1); 

f) include the allocated STI (i.e., the E.164 number) in the Session-identifier information element; and 

2) send the II Progress message towards the originating ICS UE over the transport layer connection over which the 
II Invite message was received. 

6.2.1 .3.1 .4 Sending an II Progress message witin reason set to 1 80 

When sending an II Progress message with Progress reason set to 180 towards the originating UE, the SCC AS shall: 

1) generate an II Progress message containing the following information: 

a) the Message Type Value and a Reason Value set to indicate the message is an II Progress message, 
accordance with table 7.3.1; 

b) the stored Call-Identifier field (as specified in subclause 7.2.2.1.4) that uniquely identifies this II session 
between the ICS UE and SCC AS ; and 

c) add one to the stored Sequence-ID header value. Store and include the Sequence-ID header value; and 

2) send the II Progress message towards the originating ICS UE over the transport layer connection over which the 
II Invite message was received. 

6.2.1.3.1.5 Sending an II Success message 

When sending an II Success message towards the orginating ICS UE, the SCC AS shall: 

1) generate an II Success message containing the following information: 

a) a Message Type Value and a Reason Value set to indicate the message is an II Success message, accordance 
with table 7.3.1; 

b) a Call-Identifier field containing the Call-Identifier value that uniquely identifies this II session between the 
ICS UE and SCC AS; 

2) add one to the stored Sequence-ID header value. Store and include the Sequence-ID header value; and 

3) send the II Success message towards the originating ICS UE over the transport layer connection over which the 
II Invite message was received. 

Editor's Note: have the B-Party URI header value set to the value of the P-Asserted-Identity header field in the 
received SIP 200 (OK) response is PES. 

6.2.1 .3.2 SCC AS CS Session Termination without ICS UE assisted T-ADS 

6.2.1.3.2.1 Sending an Initial II Invite message 

When sending an II Invite towards the ICS UE, the SCC AS shall: 
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1) perform the procedures per 3GPP TS 24.292 subclause 10.4.4 item 1; 

lA) dynamically allocate a STL The STI is specified as an E.164 number; 

NOTE 1: The STI value uniquely identifies the II session being established, and it may be subsequently used to 
refer to this II session, e.g. the SCC AS uses the STI to correlate the access transfer request received via 
the PS access with the active session established via the II interface. 

2) create an II Invite message that includes: 

a) a Message Type Value and a Reason Value set to indicate the message is a Mobile Terminated II Invite 
message, accordance with table 7.3.1; 

b) a Call-Identifier field, that includes an allocated Call-Identifier (Part-2) subfield, (see subclause 7.2.2.1.4). 
The Call-Identifier field in spite of containing only the Part-2 value uniquely identifies this II session between 
the ICS UE and SCC AS; 

c) a Sequence-ID; 

d) a From information element that identifies the remote calling party, if available; 

NOTE 2: The SCC AS will include in the From-id information element the remote calling party only if it is an 
E.164 number. 

e) a To information element that; 

- if the UE has previously SIP registered as specified in 3GPP TS 23.218 [17] and the R-URI is a SIP URI 
and the R-URI can be derived (see annex A) then if the R-URI in the received SIP INVITE request is; 

i) the default public user identity as derived in Annex A for the terminating UE then the Identity 

Information IE (see table 7.3.2.2) Code Specific IE is set to "Unspecified" (see table 7.4.2.3.1-2) and 
the length IE is set to 0. 

ii) is not the default public user identity for terminating UE but matches one of the public user identities 
then the Identity Information IE (see table 7.3.2.2) Code Specific Information element is set to 
"Identifier" (see table 7.4.2.3.1-2) and the length IE is set to 1 and the Information Element body of 
the To header shall be the identifier value that was derived (see annex A) and maps to the Public User 
Identity that was received in the R-URI in the SIP INVITE request. 

otherwise Identity Information IE (see table 7.3.2.2) Code Specific Information element set to 

i) a "SIP URI" (see table 7.4.2.3.1-2) if the public user identity is a SIP URI and the Information body 
(see table 7.3.2.2) containing the SIP URI. 

ii) an "International number" (see table 7.4.2.3.1-2), if the public user identity is a Tel URI or SIP URI 
with URI parameter user=phone and the Information body (see table 7.3.2.2) containing the digit 
string contained in the URI. 

f) a Privacy information element set to the value requested by the remote calling party, if available; 

g) a SCC-AS-id information element that contains an SCC AS PSI DN set to the E.164 number allocated by the 
SCC AS itself as per procedures per 3GPP TS 24.292 subclause 10.4.8 item 2; 

h) a Session-identifier information element that contains the allocated STI; and 

i) a Timestamp information element that includes current local time measured in seconds. The element will be 
used by the ICS UE to determine the staleness of the message. 

3) store the information sent in the II Invite message against the allocated SCC AS PSI DN; and 

4) select the transport layer protocol depending on the access network type, and forward the II Invite message 
toward the ICS UE. 

Subsequently the SCC AS may receive either an II Success message or an II Progress message (with Reason subfield 
set either to Ringing or Call progressing) from the ICS UE. 
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6.2.1 .3.2.2 Receipt of an 11 Progress message 

When the SCC AS receives either an II Progress message (with Reason subfield set either to Ringing or Call 
progressing), the SCC AS shall: 

1) verify if a II session exists for the received Call-Identifier value; 

2) verify if the message is in sequence according to the Sequence-ID header value 

3) store the II Progress with reason. 

NOTE 5: The SCC AS will use the information received in the II Progress message (with Reason subfield set 
either to Ringing or Call progressing) and the information saved in step 2 when handling a SIP session with the 
remote party. 

6.2.1 .3.3 SCC AS CS Session Termination with ICS UE assisted T-ADS 

The SCC AS shall generate an II Invite message to the terminating ICS UE as specified in subclause 6.2.1.3.2.1 with 
the following addition: 

1) Include a Replaces header in the II (Augmentation) Invite message, which is set to a value identical to (or 
deduced from) the SIP session identifier in the previous SIP INVITE request, to indicate that it is session control 
fallback from Gm to II ; 

2) Indicate that the pubhc user identity, the To IE value and the SCC AS PSI DN are in the correlated SIP INVITE 
request, by setting the Identity Information IE (see table 7.3.2.2) Code Specific Information element to 
"Unspecified" (see table 7.4.2.3.1) and the length IE is set to 1 and octet 3 is set to all "0"s. 

NOTE: In this case, some headers (e.g.. Privacy header) can be omitted from the II Invite message, for the 
information can be get by the ICS UE from the correlated SIP INVITE request. 

6.2.1.3.4 Failure 
The SCC AS shall: 

1) create an II Failure message that includes: 

a) a Message type subfield set to the value that indicates that this is an II Failure message; 

b) set the reason value (see table 7.3.1) to the same value as received in the status code as specified in 
subclauses 21.3 to 21.6 of RFC 3261 [6]; 

b) generate a Call-ID that identifies the transaction between the ICS UE and SCC AS. Include the Call-ID 
header value in the II Failure; 

c) generate a Sequence-ID. Include the Sequence-ID header value in the II Failure Message; 

e) if a contact header value as specified in subclause 21 .3 of RFC 3261 [6] was received in the SIP error 
response include individual To-id information elements containing the URI contents of each contact header 
field. 

f) if reason-phrase header as specified in subclauses 21.3 to 21.6 of RFC 3261[6] was received, insert the 
contents of the reason-phrase header into the Reason Phrase information element (see table 7.3.8.1). 

6.2.2 Void 

6.2.3 Session release 
6.2.3.1 General 

II sessions can be torn down by the II session release requests and by receipt of a DISCONNECT message as specified 
in 3GPP TS 24.008 [3]. An II Bye message is an II session release request. 
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6.2.3.2 Detailed behaviour of ICS UE 

When the ICS UE releases an II session using the II session control channel by sending an II Bye message, it shall: 

1) set the Call-ID to a value that identifies the II session between the ICS UE and SCC AS. Include the Call-ID 
header value in the II Bye; 

2) set the Sequence-ID. Include the Sequence-ID header value in the II Bye message; 

3) a From-id information element that includes either a SIP URI or an E.164 number, and it will be used by the 
SCC AS to identify the ICS UE; 

Editor"s note: How to include the SIP URI into the II messages is FFS. 

4) a To-id information element that includes either a SIP URI or an E.164 number, and will be used by the SCC AS 
to determine the identity of the called user; 

5) a Privacy information element that indicates the ICS UE's privacy preferences. The SCC AS will apply these 
preferences to the SIP session that the SCC AS will establish on behalf of the UE; 

6) a CS access network type indicator; and 

7) if there are no more II service control sessions using the CS bearer, set the CS bearer release timer value. 

Editor" s note: For voice calls is there a need to include any SDP type of information, by the virtue of using II in the 
context of this contribution it can be implied that CS voice is being used. 

If the CS bearer release timer expires, the ICS UE shall send a DISCONNECT message to the MSC Server as specified 
in 3GPP TS 24.008 [3], if needed. 

Subsequently, if the ICS UE receives an II Success message from the SCC AS, it shall: 

1) verify if a II session exists for the received Call-Identifier value; 

2) verify if a the message is in sequence according to the Message sequence number value; and 

3) consider the II session to be released, if verification was successful and clear the CS bearer release timer value. 
Editor" s note: Responses indicating an error are FFS. 

When the ICS UE releases a II session using the II session control channel by receiving an II Bye message, it shall: 

1) if there are no more II service control sessions using the CS bearer, the ICS UE shall send a DISCONNECT 
message to the MSC Server as specified in 3GPP TS 24.008 [3], if there are no more II service control sessions 
using the CS bearer; 

2) if there are more II service control sessions using the CS bearer, the ICS UE shall transmit a II Success 
message, containing the following information: 

a) a Message type subfield set to the value that indicates that is an II Success message; 

b) the stored Call-Identifier value that uniquely identifies this II session between the ICS UE and SCC AS; and 

c) increment the stored Message sequence value, store it, and include it in the Message sequence subfield. 
Editor's Note: the support for multiple II service control sessions is FFS. 

When the ICS UE receives a DISCONNECT message to release the CS bearer as specified in 3GPP TS 24.008 [3]: 

the CS bearer release timer expires shall be cleared, if needed; 

- if the ICS UE has a SIP REGISTER request associated with the ongoing CS call, the UE shall send a SIP 
relNVITE request requesting the media over the CS bearer to be deleted. 

If the ICS UE receives a SIP relNVITE request requesting the media over the CS bearer to be deleted and a 
DISCONNECT message for the CS bearer was already received, the ICS UE shall accept the request to delete the 
media over the CS bearer. 
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6.2.3.3 Detailed behaviour of SCC AS 

6.2.3.3.1 Sending 11 BYE to UE 

The SCC AS enhanced for II releases a session by generating and sending an II Bye message, containing the 
information: 

0) a Message Type Value and a Reason Value set to indicate the message is an II BYE message, accordance with 
table 7.3.1; 

1) set the Call-ID to a value that identifies the II session between the ICS UE and SCC AS. Include the Call-ID 
header value in the II Bye; 

2) set the Sequence-ID. Include the Sequence-ID header value in the II INVITE. 

3) include a From-id information element that identifies the remote calling party, if available; 

4) include a To-id information element that includes the E. 164 number of the ICS UE; 

5) include a Privacy information element set to the value requested by the remote calling party, if available; 

6) include a SCC-AS-id information element that contains an SCC AS DN set to the E.164 number allocated by the 
SCC AS itself; and 

7) store the information sent in the II Bye message against the allocated SCC AS PSI DN. 

6.2.3.3.2 Receipt II Success from UE 

If the SCC AS receives an II Success message from the ICS UE, it shall: 

1) verify if a II session exists for the received Call-Identifier value; 

2) verify if a the message is in sequence according to the Message sequence number value; and 

3) consider the II session to be released, if verification was successful. 

If any of the operations in 1) or 2) fail the II Success message shall be discarded. 
Editor" s note: Responses indicating an error are FFS. 

6.2.3.3.3 Receipt II BYE from UE 

The SCC AS shall transmit an II SUCCESS message using the II session control channel, it shall containing the 
following information: 

a) a Message Type Value and a Reason Valueset to indicate the message is an II Success message, accordance 
with table 7.3.1; 

b) the stored Call-Identifier value that uniquely identifies this II session between the ICS UE and SCC AS; and 

c) increment the stored Message sequence value, store it, and include it in the Message sequence subfield. 

6.2.4 Adding 11 control to existing CS session (11 Augmentation) 
6.2.4.1 General 

Standard CS procedures can be used to deliver the incoming session to the ICS UE as specified in 3GPP TS 24.292 [5] 
subclause 10.4.7 (SCC AS for call termination over CS to non-ICS UE) or originate a session as specified in 
3GPP TS 24.292 [5] subclause 7.4.3 (ICS UE using CS). Additional IMS parameters or service control can be 
optionally communicated to the ICS UE using II after the session has been setup. The ICS UE or SCC AS shall add II 
control to an existing session only when there is a single session over CS. 
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6.2.4.2 Detailed behaviour of ICS UE 

If the ICS UE wants to add II control to an existing session that was established without II and Gm, it shall send an II 
Invite message over II. The ICS UE shall populate the II Invite message as specified in subclause 6.2.1.2.1 with the 
following additions: 

1) set the To information element to the static STI; 

NOTE: In this case, some information elements (e.g. From, Privacy) can be omitted from the II Invite message, 
for the information is already known for the ongoing session. 

Upon receiving an II Success message, the ICS UE shall treat the ongoing session as established using II. 

If the ICS UE receives a new II Invite message containing a SCC AS PSI DN which matches the B-party number of the 
ongoing session that was established without II and Gm, the ICS UE shall: 

1) respond to the II Invite message with an II Success message; and 

2) treat the ongoing session as established using II. 

6.2.4.3 Detailed behaviour of SCC AS 

If the SCC AS receives an II Invite message containing the static STI in the To information element, the SCC AS shall 
determine if this II Invite message is for an ongoing session using STI or CS domain number (e.g., MSISDN) from 
transport layer. If the ICS UE has an ongoing session, the SCC AS shall: 

1) respond to the II Invite message with an II Success message; and 

2) treat the ongoing session as established using II. 

If the SCC AS wants to add II control to an existing session that was established without Gm and II, the SCC AS shall 
send a new II Invite message over II reference point. The SCC AS shall populate the II Invite message as specified in 
subclause 6.2.1.2.2 with the following addition: 

1) include a SCC AS PSI DN which matches the B-party number of the ongoing session. 

NOTE: In this case, some information elements (e.g. From, To, Privacy ) can be omitted from the II Invite 
message, for the information is already known for the ongoing session. 

Upon receiving an II Success message, the SCC AS shall treat the ongoing session as established using II. 

6.2.5 Service control transfer (Gm fallback to 11 ) 
6.2.5.1 General 

When the Gm reference point is used for service control signalling, a change of access network due to handover (e.g. as 
described in 3GPP TS 23.009 [10] and 3GPP TS 25.413 [11]) may result in an inability to use the PS access for the Gm 
reference point. In this case, if the II interface in the target access network is available and supported, the service 
continuity may be maintained by switching the service control signalling from the Gm reference point to the II 
interface. 

If the ICS UE discovers that the Gm reference point is not available for an ongoing session that is using a CS bearer 
which was established over the respective Gm reference point, the ICS UE can transfer the service control signalling 
from the Gm reference point to the II interface, if the II interface is available, while retaining the existing CS bearer 
(i.e. the existing CS bearer is left intact). However, if prior to the change of the access network, the UE was not attached 
to the CS domain and a PS bearer was used for either the voice media or voice and video media of the IMS session, then 
the service continuity may be maintained by switching the service control signalling from the Gm reference point to the 
II interface and transferring the voice media or voice and video media from the PS bearer to the newly-established CS 
bearer. 
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6.2.5.2 Service continuity wliiie retaining the use of CS access for media 

6.2.5.2.1 Detailed behaviour of ICS UE 

When the ICS UE, that has an established IMS session that is using the CS media, originates a service control transfer 
from the Gm reference point to the II reference point while retaining the existing CS bearer and associated media intact, 
the ICS UE shall behavemessage as specified in the subclause 6.2.1.2.1 with the following additions: 

1) include a Replaces information element in the II Invite (Augmentation) message that contains a STI. The STI 
identifies the SIP dialog that was previously established over the Gm reference point on the Source Access Leg 
and will be transferred to this II session on the Target Access Leg. 

2) Indicate that the public user identity and the To header value are in the correlated SIP INVITE request, by setting 
the Identity Information IE (see table 7.3.2.2) Code Specific Information element to "Unspecified" (see 

table 7.4.2.3.1) and the length IE is set to 1 and octet 3 is set to all "0"s. 

NOTE 1: In this case, some II information elements (e.g. Privacy) can be omitted from the II Invite message, since 
thisinformation is already known to the SCC AS from the ongoing SIP dialog that was previously 
established over the Gm reference point on the Source Access Leg. For example, the inclusion of SIP URI 
into the To-id and From-id information elements is not needed since these information elements may be 
omitted from the II Invite message. 

NOTE 2: It is assumed that when the SIP dialog was established over the Gm reference point, the respective STI 
was used to identify this SIP dialog. 

Upon receiving the II Progress message from the SCC AS, the UE shall not initiates the call setup over the CS domain 
by sending a CC SETUP message to the MSC Server, since the II session will inherit the existing CS media (i.e. the 
existing CS bearer is left intact). 

When the ICS UE receives an II Success message from the SCC AS, the UE shall consider the service control 
signalling as being transferred from the Gm reference point to the Ilinterface and the associated CS media as being 
transferred to the II session (i.e. the II session is now controlling the inherited CS media). Furthermore, the UE shall 
considered the SIP dialog on the Source Access Leg that was originally set using the Gm reference point and all 
remaining PS media associated with this SIP dialog (i.e. the PS media that were not transferred), if any, as terminated. 

NOTE 3: If the UE is incapable of simultaneously communicating over the Gm reference point on the Source 

Access Leg and the II interface over the Target Access Leg, the UE will not receive a SIP BYE request 
from the ICS AS sent over the Gm reference point on the Source Access Leg. 

NOTE 4: Irrespective whether the UE receives a SIP BYE request over Gm reference point on the Source Access 
Leg or not, the UE will consider the SIP dialog on the Source Access Leg and all remaining PS media 
associated with this SIP dialog (i.e. the PS media that were not transferred), if any, as terminated. 

6.2.5.2.2 Detailed behaviour of SCC AS 

If the SCC AS, that supports the II protocol, receives an initial II Invite message with a Replaces information element 
that contains a STI, the SCC AS shall use the STI to identify an existing SIP dialog that was previously established 
using the Gm reference point on the Source Access Leg, and will be replaced with the II session on the Target Access 
Leg. If the identified SIP dialog on the Source Access Leg is currently using a CS bearer, the SCC AS shall behave as 
specified in subclause 6.2.1.3.1 with the following addition: 

1) interpret the received II Invite message containing the Replaces information element as request for service 
control transfer from Gm reference point on the Source Access Leg to the II interface on the Target Access Leg; 

2) correlate the II Invite message with the existing SIP dialog that is using a CS bearer, based on the STI included 
in the Replaces information element; 

NOTE 1: In this case, some information elements (e.g. To-id, From-id, Privacy) may not be included in the II 
Invite message. The omitted II information elements are already known to the SCC AS from the 
ongoing SIP dialog that was previously established over the Gm reference point on the Source Access 
Leg. 

3) send the II Progress message towards the originating UE that does not include an allocated SCC AS PSI DN; 
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NOTE 2: Upon sending the II Progress message towards the originating UE, the SCC AS will not receive an initial 
SIP INVITE request from the CS domain, since the existing CS media will be left intact and only the 
control will be transferred from the SIP dialog identified by the STI in the received Replaces information 
element to the II session being established. 

4) examine whether the SIP dialog on the Source Access Leg has a single CS bearer (i.e. no PS bearers) associated 
with this SIP dialog, or there are additional PS bearers (in addition to the CS bearer) associated with this SIP 
dialog. 

a) if there is a single CS bearer and no PS bearers associated with this SIP dialog, the SCC AS proceeds with 
the steps below, starting with the step 5; or 

NOTE 3: In spite of the service control being transferred from the Gm reference point to the II interface, there is no 
need to update the remote UE by sending a new SDP offer since the CS media has been left intact. 

b) if, in addition to a CS bearer, there are additional PS bearers associated with this SIP dialog, the SCC AS 
shall proceed as follows: 

i) send a SIP re-INVITE request toward the CS domain (e.g. MGCP) that does not contain an SDP offer; 

ii) upon receiving an SDP offer from the CS domain (in the response to the SIP re-INVITE request), the 
SCC AS update the remote UE by sending a SIP re-INVITE request toward the the remote UE. The SDP 
offer included in the SIP re-INVITE request sent toward the the remote UE contains the information 
received in the SDP offer from the CS domain and terminates all the PS bearers, as per standard SIP 
procedures; 

iii) upon receiving the SDP answer in the response to the SIP re-INVITE request from the remote UE, the 
SCC AS sends an SIP ACK toward the CS domain (e.g. MGCF) that contains an SDP anwer. The SDP 
answer contains the information obtained from the SDP answer conveyed in the response to the SIP re- 
INVITE request received from the remote UE. In addition, the SCC AS sends a SIP ACK toward the 

remote UE; 

iv) proceeds with the steps below; 

5) release the SIP dialog on the Source Access Leg by sending a SIP BYE request via the SIP dialog over the Gm 
reference point on the Source Access Leg, if the SIP dialog is still active; and 

NOTE 4: The SIP dialog may have been released by the IMS core network as specified in 3GPP TS 24.229 [12], 
subclause 5.2.8.1.2. 

NOTE 5: If the UE is incapable of simultaneously communicating over the Gm reference point on the Source 
Access Leg and the II interface over the Target Access Leg, the SCC AS will not receive a 200 (OK) 
response to a SIP BYE request. 

NOTE 6: Irrespective whether the SCC AS receives a 200 (OK) response to the SIP BYE request over the Gm 
reference point on the Source Access Leg or not, the SCC AS will consider the dialog on the Source 
Access Leg and all remaining PS media associated with this dialog (i.e. the PS media that were not 
transferred), if any, as terminated. 

6) send an II Success message to the UE over the II interface. Upon sending the II Success message to the UE, the 
SCC AS shall consider the service control signalling as being transferred from the Gm reference point to the II 
interface and the associated CS media as being transferred to the II session (i.e. the II protocol is now 
controlling the inherited CS media). 

6.2.5.3 Service continuity when transferring from PS access to CS access 

When an UE, that has an established SIP dialog that is using only the PS media (i.e. no CS media) and the Gm reference 
point for service control signalling (e.g. the UE is not attached to the CS domain), determines that the Gm reference 
point is not anymore available, the UE may maintain service continuity by switching the service control signalling from 
the Gm reference point to the II reference point and an associated PS bearer to the CS bearer. 

The II protocol is used to transfer either a single PS voice media or a single PS voice and PS video media session to a 
single CS bearer. If there are more then one active PS voice media or PS voice media and PS video media associated 
with the SIP dialog being transferred, then the last-established active PS voice media or PS voice and PS video media 
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will be transferred from the PS domain to the CS domain. If there are only inactive PS voice media or PS voice and PS 
video media associated with the SIP dialog, then the last-established inactive PS voice media or PS voice and PS video 
media will be transferred from the PS domain to the CS domain. In either case, the SIP dialog and all associated PS 
media that were not transferred are terminated. 

If the transferred media was active prior to the transfer, it shall stay active upon the completion of the transfer 
procedure. Likewise, if the transferred media was inactive prior to the transfer, it shall stay inactive upon the completion 
of the transfer procedure. 

6.2.5.3.1 Detailed behaviour of UE 

When the UE, that has an established SIP dialog that is using only the PS media (i.e. no CS media), transfers the service 
control signalling from the Gm reference point to the II interface and either the voice media or the voice and video 
media from the PS access to the CS access, the UE behave as specified in subclause 6.2.1.2.1 with the following 
additions: 

1) include a Replaces information element in the II Invite message that contains the STL The STI identifies the SIP 
dialog that was previously established over the Gm reference point on the Source Access Leg and will be 
transferred to the II session on the Target Access Leg. 

NOTE 1: In this case, some II information elements (e.g. To-id, From-id, Privacy) can be omitted from the II 

Invite message, since this information is already known to the SCC AS from the ongoing SIP dialog that 
was previously established over the Gm reference point on the Source Access Leg. For example, the 
inclusion of SIP URI into the To-id and From-id information elements is not needed since these 
information elements may be omitted from the II Invite message. 

NOTE 2: It is assumed that when the SIP dialog was established over the Gm reference point, the respective STI 
was used to identify this SIP dialog. 

When the UE receives an II Progress message from the SCC AS that contains an lUA PSI DN, the UE shall initiates a 
call over the CS domain using the received lUA PSI DN, as specified in subclause 6.2.1.2.1. 

When the UE receives an II Success message from the SCC AS, the UE shall consider the service control signalling as 
being transferred from the Gm reference point to the Ilinterface and the associated voice media or voice and video 
media as been transferred from the PS domain to the CS domain. Furthermore, the UE shall considered the SIP dialog 
on the Source Access Leg that was originally set using the Gm interface and all remaining PS media (i.e. the PS media 
that were not transferred), if any, associated with this SIP dialog as terminated. 

NOTE 3: If the UE is incapable of simultaneously communicating over the Gm reference point on the Source 

Access Leg and the II interface over the Target Access Leg, the UE will not receive a SIP BYE request 
from the SCC AS over the Source Access Leg. 

NOTE 4: Irrespective whether the UE receives a SIP BYE request over the Gm reference on the Source Access Leg 
or not, the UE will consider the dialog on the Source Access Leg and all remaining PS media associated 
with this SIP dialog that were not transferred, if any, as terminated. 

6.2.5.3.2 Detailed behaviour of SCC AS 

If the SCC AS that supports the II protocol receives an initial II Invite message with a Replaces information element 
that contains a STI, the SCC AS shall use the STI to identify an existing SIP dialog that was previously established 
using the Gm reference point on the Source Access Leg and will be replaced with the II session on the Target Access 
Leg. If the identified SIP dialog on the Source Access Leg is currently using only PS media, the SCC AS shall behave 
as specified in subclause 6.2.1.3.1 with the following addition: 

1) interpret the received II Invite message containing the Replaces information element as request for service 
control transfer from Gm reference point on the Source Access Leg to the II interface on the Target Access Leg; 

2) correlate the II Invite message to an existing SIP dialog (and is using only PS bearers), based on the STI 
received in the Replaces information element, and select a PS bearer that is using either a voice media or voice 
and video media and that will be transferred to the CS bearer; 
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NOTE 1 : If there are more then one active PS voice media or PS voice media and video media associated with the 
SIP dialog, the SCC AS selects the last-established active PS voice media or PS voice and video media. If 
there are only inactive PS voice media or PS voice and video media associated with the SIP dialog, then 
the SCC AS selects the last-established inactive PS voice media or PS voice and video media. 

3) send the II Progress message towards the originating UE that includes an allocated SCC AS PSI DN, as 
specified in subclause 6.2.1.3.1; 

Upon receiving the initial SIP INVITE request from the CS domain, the SCC AS shall updates the Remote Leg by 
sending an SIP re-INVITE request toward the remote UE that include an SDP offer. The SDP offer included in the SIP 
re-INVITE request sent toward the the remote UE specifies which media is being transferred to the CS domain, and 
which PS media, if any, are being terminated. When generating the SDP offer towards the remote UE, the SCC AS shall 
use the information received in the SDP offer in the SIP INVITE request received from the CS domain and terminates 
all the PS bearers that have not been transferred to the CS domain, as per standard SIP procedures. 

Upon receiving a SIP 200 (OK) response from the remote UE that contains an SDP answer, the SCC AS shall send the 
SIP 200 (OK) response towards the CS domain that includes a SDP answer. The SDP answer sent towards the CS 
domain contains the media information that pertains to the voice media or voice and video that has been received in the 
SDP answer from the remote UE and is being transferred to the CS domain. 

Upon receving a SIP ACK request from the CS domain, the SCC AS shall send a SIP ACK tovard the remote UE, and: 

release the SIP dialog on the Source Access Leg by sending a SIP BYE request via the SIP dialog over the Gm 
reference point on the Source Access Leg, if the SIP dialog is still active; and 

send an II Success message toward the UE over the II interface. 

NOTE 2: The SIP dialog may have been released by the IMS core network as specified in 3GPP TS 24.229 [12], 
subclause 5.2.8.1.2. 

Upon sending the II Success message to the UE, the SCC AS shall consider the service control signalling as being 
transferred from the Gm interface to the Ilinterface and the associated CS media as being transferred to the II session 
(i.e. the II protocol is now controlling the transferred CS media). 

NOTE 3: If the UE is incapable of simultaneously communicating over the Gm reference point on the Source 
Access Leg and the II interface over the Target Access Leg, the SCC AS will not receive a 200 (OK) 
response to the SIP BYE request from the UE. 

NOTE 4: Irrespective whether the SCC AS receives a 200 (OK) response to the SIP BYE request over the Gm 
reference point on the Source Access Leg or not, the SCC AS will consider the dialog on the Source 
Access Leg and all non-transferred PS media associated with this dialog, if any, as terminated. 

6.3 Supplementary services control procedures 
6.3.1 Line ID Services (OIP, OIR, TIP, TIR) 

6.3.1.1 Originating Identity Presentation (OIP) 

The procedures in subclause 6.2.1.2.1 apply. The From-id information element is used to present the originating 
identity. 

6.3.1 .2 Originating Identity Restriction (OIR) 

The procedures in subclause 6.2.1.2.1 apply with following addition: 

1) a Privacy information element that indicates the ICS UE wants to restrict the presentation of the originating 
identity. 
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6.3.1 .3 Terminating Identity Presentation (TIP) 

The procedures of sending an II Success message towards the orginating UE in subclause 6.2.1.3.1 apply with 
following addition: 

1) a To-id information element that includes either a SIP URI or an E.164 number, and will be used to present the 
terminating identity. 

6.3.1.4 Terminating Identity Restriction (TIP) 

The procedures of sending an II Success message towards the orginating UE in subclause 6.2.1.3.1 apply without a To- 
id information element. 

6.3.2 Communication diversion services (CDIV) 

6.3.2.1 Communication Forwarding Unconditional (CFU) 

No specific II related messages. 

6.3.2.2 Communication Forwarding on Not Logged-in (CFNL) 

No specific II related messages. 

6.3.2.3 Communication Forwarding Busy (CFB) 

If the ICS UE receives an II Invite message from the SCC AS, and the UE determines that the user is busy, the ICS UE 
shall: 

1) generate an II Failure message that includes: 

a) a Message type subfield set to the value that includes that this is an II Failure message; 

b) a new value in the Call-Identifier (Part-1) subfield, as specified in subclause 7.2.2. The Call-Identifier will 
uniquely identify this II session between the ICS UE and the SCC AS; 

NOTE 1: A new value in the Call-Identifier (Part-1) subfield is inserted only if this is the first II message sent to 
the SCC AS. Otherwise the previously set Call-Identifier value is used. 

c) increment the stored Message sequence value, store it, and include it in the Message sequence subfield; and 

d) set the Error-code information element to 486; and 

2) send the II Failure message towards the SCC AS over the transport layer connection over which the II Invite 
message was received. 

6.3.2.4 Communication Forwarding No Reply (CFNR) 

No specific II related messages. 

6.3.2.5 Communication Forwarding on Subscriber Not Reachable (CFNRc) 

If the ICS UE receives an II Invite message from the SCC AS, and the UE determines that the user is busy, the ICS UE 
shall: 

1) generate an II Failure message that includes: 

a) a Message type subfield set to the value that includes that this is an II Failure message; 

b) a new value in the Call-Identifier (Part-1) subfield, as specified in subclause 7.2.2. The Call-Identifier will 
uniquely identify this II session between the ICS UE and the SCC AS; 
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NOTE 1: A new value in the Call-Identifier (Part-1) subfield is inserted only if this is the first II message sent to 
the sec AS. Otherwise the previously set Call-Identifier value is used. 

c) increment the stored Message sequence value, store it, and include it in the Message sequence subfield; and 

d) set the Error-code information element to 480; and 

2) send the II Failure message towards the SCC AS over the transport layer connection over which the II Invite 
message was received. 

6.3.2.6 Communication Deflection (CD) 

If the ICS UE receives an II Invite message from the SCC AS, and the UE determines that deflect the call, the ICS UE 
shall: 

1) generate an II Redirection message that includes: 

a) a Message type subfield set to the value that includes that this is an II Failure message; 

b) a new value in the Call-Identifier (Part-1) subfield, as specified in subclause 7.2.2. The Call-Identifier will 
uniquely identify this II session between the ICS UE and the SCC AS; 

NOTE 1: A new value in the Call-Identifier (Part-1) subfield is inserted only if this is the first II message sent to 
the SCC AS. Otherwise the previously set Call-Identifier value is used. 

c) increment the stored Message sequence value, store it, and include it in the Message sequence subfield; and 

d) To-id information element set to either a SIP URI or an E. 164 of the C-party identity; and 

2) send the II Redirection message towards the SCC AS over the transport layer connection over which the II 
Invite message was received. 

6.3.2.7 Communication Diversion Notification (CDIVN) 

If the SCC AS wants to notify the ICS UE that the call was diverted, the SCC AS shall: 

1) generate an II Notify message that includes: 

a) a Message type subfield set to the value that includes that this is an II Notify message; 

b) increment the stored Message sequence value, store it, and include it in the Message sequence subfield; and 

c) a Mid-call information element that indicates that the call was diverted; and 

2) send the II Notity message towards the ICS UE over the transport layer connection over which other II message 
was received. 

6.3.3 Communication Barring 

No specific II related messages. 

6.3.4 Communication Hold (HOLD)/Resume 
6.3.4.1 Actions at the ICS UE 

When the ICS UE wants to hold/resume a session using an Ilreference point, the UE shall: 
1) generate an II Mid call Request message that includes: 

a) a Message type subfield set to the value that includes that this is an II Mid call Request message; 

b) increment the stored Message sequence value, store it, and include it in the Message sequence subfield; and 

c) a Mid-call information element that indicates the ICS UE wants to hold/resume the II session; and 
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2) forward the II Invite message toward the SCC AS. 

6.3.4.2 Actions at the SCC AS 

Upon receiving an II Mid call Request message with a Mid-call infromation element that indicates the II session to be 
held/resume from the ICS UE via the II reference point, the SCC AS shall: 

1) store the information received in the II Mid call Request message; 

2) generate an II Progress message containing the following information: 

a) a Message type field set to the value that indicates that is an II Progress message; 

b) include the stored Call-ID header value; 

c) add one to the stored Sequence-ID header value. Store and include the Sequence-ID header value; and 

d) set the Reason field to 183 (per figure 7.3. 1); 

3) send the II Progress message towards the originating UE over the transport layer connection over which the II 
Mid Call Request message was received. 

4) generate a new SDP offer that contains "inactive" attribute for the media streams that shall be put on 
held/resume;and 

5) send the SDP offer in an UPDATE (or re-INVITE) request towards the MGCF in order to inactive/active RTP 
media. 

6.3.5 Consultative Explicit Communication Transfer 

6.3.5.1 Actions at the ICS UE 

When ICS UE A is playing the role of transfer, the ICS UE shall: 

1) generate an II Refer message that includes: 

a) a Message type subfield set to the value that includes that this is an II Refer message; 

b) increment the stored Message sequence value, store it, and include it in the Message sequence subfield; and 

c) a Mid-call information element that indicates that this is a conference invitation; and 

2) forward the II Mid Call message toward the SCC AS. 

6.3.5.2 Actions at the SCC AS 

Upon receiving an II Mid call request message with a Mid call informtion element indicating this is a conference 
invitation from the ICS UE via the II reference point, the SCC AS shall continue session establishment towards the 
conference AS as specified in 3GPP TS 24.173 [18]. 

Upon receiving a SIP 200 OK response from conference AS, the SCC AS shall: 

1). generate an II Success message containing the following information: 

a) a Message type field set to the value that indicates that is an II Success message; and 

b) a Call-Identifier field containing the Call-Identifier value that uniquely identifies this II session between the 
UE and SCC AS; 

2) add one to the stored Sequence-ID header value. Store and include the Sequence-ID header value; and 

3) send the II Success message towards the originating UE over the transport layer connection over which the II 
Mid call request message was received. 
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6.3.6 Conference calling (CONF) 

6.3.6.1 Actions at the ICS UE 

When ICS UE A is playing the role of transfer, the ICS UE shall: 

1) generate an II Mid Call request message that includes: 

a) a Message type subfield set to the value that includes that this is an II Mid Call request message; 

b) increment the stored Message sequence value, store it, and include it in the Message sequence subfield; and 

c) a To-id information element that includes either a SIP URI or an E.164 number, and will be used to present 
the identity of the third party II sesson transferred to; and 

2) forward the II Mid Call message toward the SCC AS. 
When the ICS UE receives an II Success message, the UE shall: 

1) verify if a II session exists for the received Call-Identifier value; 

2) verify if a the message is in sequence according to the Message sequence number value; 

3) consider the call to be established, if verification was successful; and 

4) release the previous II session. 

6.3.6.2 Actions at the SCC AS 

Upon receiving an II Refer message from the ICS UE via the II reference point, the SCC AS shall: 

1) comple of referring UE B to UE C as specified in 3GPP TS 24.173 [18]; and 

2) generate an II Success message containing the following information: 

a) a Message type field set to the value that indicates that is an II Success message; and 

b) a Call-Identifier field containing the Call-Identifier value that uniquely identifies this II session between the 
UE and SCC AS; 

3) add one to the stored Sequence-ID header value. Store and include the Sequence-ID header value; and 

4) send the II Success message towards the originating UE over the transport layer connection over which the II 
Refer message was received. 

6.3.7 Communication Waiting 

No specific II related messages. 

6.4 SCC AS and ICS UE Time Synchronization 
6.4.1 General 

In order to detect stale II messages transmitted over non-realtime transports (e.g. SMS), the ICS UE and SCC AS must 
be synchronized in time. The staleness of the II messages can be determined by the following two steps: 

1) The ICS UE originates initial time synchronization procedure with the SCC AS. During this procedure both ICS 
UE and SCC AS receive an initial time of the peer. The time value is measured in seconds. The initial time value 
is not important as long as the subsequent time measurements are increased accordingly; and 

2) An II message receiver (ICS UE or SCC AS) compares the received in an II message current time of the peer 
with the initial time established in step 1, and based on the time difference between the current and initial time it 



£75/ 



3GPP TS 24.294 version 9.1 .0 Release 9 31 ETSI TS 1 24 294 V9.1 .0 (201 0-04) 

makes a decision about the staleness of the message. If the message is stale it shall be discarded and no response 
generated to the II message. 

6.4.2 Generating Time 

The initial time value can be initialized using one of the following methods: 
i) a local time of the machine or terminal; 
ii) a randomly generated time; and 
ii) zero. 

6.4.3 Detailed beinaviour of ICS UE 

The time synchronization procedure shall be initiated by the ICS UE after the initial IMS registration procedure with the 
sec AS in accordance with subclause 6.2 in 3GPP TS 24.292 [5] is completed successfully. The time synchronization 
procedure with the SCC AS may be repeated by the ICS UE if required. 

6.4.3.1 ICS UE Synchronization Origination 

When the ICS UE initiates the synchronization procedure using an Ilreference point, the UE shall: 

1) generate an II Register message that includes: 

a) a Message type subfield set to the value that includes that this is an II Register message; 

b) a new value in the Call-Identifier (Part-1) subfield, as specified in subclause 7.2.2. The Call-Identifier will 
uniquely identify this II session between the ICS UE and the SCC AS; 

c) an allocated Message sequence number; 

d) a From-id information element that includes either a SIP URI or an E.164 number, and it will be used by the 
SCC AS to identify the ICS UE; and 

e) a Timestamp information element that includes the initial time generated according to the subclause 6.4.2. 
The element will be used by the SCC AS to validate the ICS UE II messages. The Timestamp value is stored 
by the ICS UE. 

2) select the transport layer protocol depending on the access network type, and forward the II Register message 
toward the SCC AS. 

When the ICS UE receives an II Success message, the UE shall: 

3) verify if a II session exists for the received Call-Identifier value; 

4) verify if a the message is in sequence according to the Message sequence number value; and 

5) retrieve and store the Timestamp header value received in the response. 

If the ICS UE does not receive an II Success message within 64*T1 seconds, the UE shall consider the II Register 
message as failed and it may attempt to perform the synchronization procedure again after an interval of time. 

6.4.4 Detailed behaviour of SCC AS 
6.4.4.1 SCC AS Synchronization Termination 

Upon receiving an II Register message from the ICS UE via the II reference point, the SCC AS shall: 

1) retrieve the ICS UE time value from the Timestamp information element of the II Register message, and store 
the value; 

2) save the received Call-Identifier and Sequence-ID values and use them for further reference to this session; 
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3) generate an II Success message containing the following information: 

a) a Message type field set to the value that indicates that is an II Success message; 

b) include the stored Call-ID header value; 

c) add one to the stored Sequence-ID header value. Store and include the Sequence-ID header value; 

d) include the Timestamp information element that is generated according to the subclause 6.4.2. The element 
will be used by the ICS UE to validate the SCC AS II messages. The Timestamp value is stored by the SCC 
AS. 

4) send the II Success message towards the originating UE over the transport layer connection over which the II 
Register message was received. 

7 Protocol specification and implementation 

7.1 Overview of 11 protocol functionality 

The II protocol includes the procedures for establishing, maintaining, and clearing the II sessions between the ICS UE 
and the SCC AS (see figure 7.1). 






11 



SCC AS 
ISC 



CS Access 



MSC Server 



CSCF 

SIP signalling 

MGCF 
MGW 



Figure 7.1 UE session signalling and bearer path using II interface for Service Control Signalling 

Path 

NOTE 1: Figure 7.1 illustrates an MSC server that is not enhanced for ICS. II can also be used when deploying an 
MSC server enhanced for ICS as specified in 3GPP TS 23.292 [2]. 

The II protocol is a message based point-to-point protocol. The II protocol messages are wrapped in a point-to-point 
transport layer connection protocol (e.g. USSD) and are exchanged between the ICS UE and the SCC AS. Therefore, 
the II protocol does not include any routing capabilities. To address the ICS UE in CS network and establish a 
transport-layer connection, (the lUA of) the SCC AS shall convert the called party identity (i.e., IMS public user 
identity) to the CS domain party identity that is required to route the transport layer protocol(i.e., MSISDN, MDN, etc.). 

The II protocol assumes that there is an associated connection-control protocol that incorporates media negotiation 
capabilities and provides the setting up and clearing of the connection over which the media will be exchanged. 
Therefore, any signalling between the UE and the CS access domain (see figure 7.1), as well as the SIP signalling 
between the MGCF and the SCC AS should be viewed as a procedure to establish a media connection rather then a call 
control signalling. Obviously, the II endpoints will correlate and synchronize the progress of the II session 
establishment and clearing of the II session with the associated media-establishing procedures. 

NOTE 2: The primitives that are used to communicate between the II protocol II session entity and the associated 
connection-control protocol entity, internally in the UE and SCC AS, respectively, are not specified in 
this document. 

The II protocol assumes that the application level segmentation of the II protocol messages is not supported. The size 
of the II protocol messages is constrained by the limits of the transport-layer message size. For example, USSD allows 
for a message size of 160 octets. This means that it is not possible to send an II protocol message greater than 160 
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octets, unless message segmentation is designed into the II protocol. A USSD dialogue is already segmented by the use 
of USSD sub-dialogues as a USSD conversation, and this usage of USSD is inappropriate for the II protocol. 

The II protocol is a transport-independent protocol, i.e. the II protocol II session control entities can exchange the II 
protocol messages over any transport-layer connection that connects the ICS UE and the SCC AS. The ICS UE sends 
the II protocol messages to the SCC AS over a transport-layer connection (e.g. USSD) that the ICS UE knows it will 
reach the SCC AS. Likewise, The SCC AS sends the II protocol messages to the ICS UE over a transport-layer 
connection (e.g. USSD) that the SCC AS knows that it will reach the ICS UE. For example, the SCC AS forwards the 
II protocol message to the ICS UE over the same transport-layer connection (e.g. USSD) over which it received the 
previous II protocol message from the ICS UE. 

The II protocol message are self-identifying, i.e. the information contained in the II protocol message uniquely 
identifies the call to which the II protocol message pertains to. 

The II protocol assumes that when the transport-layer connection is established between the UE and SCC, the UE's 
E.I 64 number is bound to the respective transport-layer connection at both the UE and SCC AS (e.g. the establishment 
of an USSD channel can implicitly bind the UE's E.164 number to this transport-layer connection). Subsequently, the 
request for an II session destined for the respective E.164 number will be passed to the UE over the respective 
transport-layer connection. 

NOTE 3: Since the binding between the transport-layer connection and the E.164 number is performed when the 
transport-layer connection is established, the II protocol does not include any registration procedure. 

The II protocol is a binary-oriented protocol (i.e. the II messages are binary encoded). The bit-map tables are used to 
describe the II messages and associated information elements. 

In this release of this document, it is assumed that the ICS UE, when establishing a transport-layer connection (e.g. 
USSD channel) to the SCC AS, will have been authenticated by the CS domain. Due to a relationship between the SCC 
AS and the CS domain, the ICS UE is not authenticated (e.g. challenged) by the SCC AS when sending any II protocol 
message to the SCC AS. However, the SCC AS will check the UE identity for potential invalid IMS public user identity 
included by the ICS UE. The CS domain number received from the transport-layer is trustable and will be used by (the 
lUA of) the SCC AS to check the URI of the UE before the SCC AS provides SIP UA behaviour on behalf of the ICS 
UE. 

7.2 11 -protocol messages and functional definition 

7.2.1 II -protocol messages 
7.2.1.1 General 

This subclause provides the list of Il-protocol messages (see table 7.2.1) and brief description of each Il-protocol 
message. Based on their function the Il-protocol messages can be grouped into five categories: 

Il-Session establishment messages; 
- II -Stable Session messages; 

Il-Session clearing messages; 

II -Error messages; 

II- Supplementary Service -Invocation messages;and 

II -Other messages. 
Editor's note: a definition of the term stable II session is EPS 
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Table 7.2.1.1 : II -protocol messages 



Message type 


Description and 

content 

(subclause) 


Session establishment messages: 


7.2.1.2 


11 Invite message 
11 Progress message 
11 Success message 








Stable Session messages: 


7.2.1.3 


11 Refer message 




Session clearing messages: 


7.2.1.4 


11 Bye message 
11 Success message 




Error messages: 


7.2.1.5 


11 Failure message 




Supplementary Service Invocation messages: 


7.2.1.6 


11 IVIid Call Request message 
11 Redirection message 
11 Notify message 




Other messages: 




11 Dummy message 


7.2.1.7 



7.2.1.2 



Session establishment messages 



The session establishment II messages can be sent either by the ICS UE to the SCC AS or by the SCC AS to the ICS 
UE. 

II Invite message 

The II Invite message is sent either by the calling UE to the SCC AS or by the SCC AS to the called UE to initiate 
session establishment. 

II Progress message 

The II Progress message is a general purpose provisional response, semantically similar to SIP Ixx class responses. The 
binary Reason field value (per figure 7.3.1) corresponds with the received SIP Ixx response's numeric status-code 
value. 

II Success message 

The II Success message indicates that the action requested in the respective II message has been accomplished 
successfully. 

The II Success message: 

is transmitted by the SCC AS to the calling UE to indicate that the session has been accepted; or 

is transmitted by the called UE to the SCC AS to indicate that the called UE has accepted the session. 

The Reason's corresponding to the II Success message are specified in table 7.3.1 and correspond with a SIP 2xx 
response's numeric status-code. 



7.2.1.3 



Stable session messages 



II Refer message 

The II Refer message is sent either by the ICS UE to the SCC AS or by the SCC AS to the ICS UE to indicate that the 
recipient of the II Refer message should contact the target identified in the II Refer message. 



£75/ 



3GPP TS 24.294 version 9.1 .0 Release 9 35 ETSI TS 1 24 294 V9.1 .0 (201 0-04) 

7.2.1.4 Session clearing messages 

II Bye message 

The II Bye message: 

is transmitted by the SCC AS to the ICS UE to clear the II session; or 
is transmitted by the ICS UE to the SCC AS to clear the II session. 

7.2.1.5 Error messages 

II Failure message 

An II Failure response message is sent either by the ICS UE to the SCC AS or by the SCC AS to the ICS UE, to 
indicate that an error has occurred. The additional parameters included in the II -Failure message indicate the type of the 
error that has occurred. The reason value field is a direct one to one mapping to the status code in the status line as 
specified in subclause 7.2 of RFC 3261 [6]. 

7.2.1 .6 Supplementary Services Invocation related messages 

The following section details the messages that are used to request the invocation of a supplementary service. 

II Mid Call Request message 

The II Mid Call Message is used for the invocation of mid-call supplementary services. For example: user wishes to 
hold or resume a call. 

II Redirection message 

The II Redirection message is used by the ICS UE to inform the SCC AS of the desire to invoke a supplementary 
service, in response to incoming signalling. For example: desire for the called user to deflect the call to a third party. 
The SCC AS interworks the II response to the appropriate SIP response to send to the SIP AS. 

II Notify message 

The II Notify message may be used to notify the UE of events related to the invocation of supplementary services. For 
example: 

Notification that a call has been forwarded to a third party; 

Notifications related to Explicit Call Transfer; or 

Notifications related to requests to join a Conference. 

7.2.1 .7 Other messages 

II Dummy message 

The II Dummy message is only used for those specific transport-layer connections (e.g., USSD) which provide two- 
way-alternative interactive service. If the party which has the turn hasn't sent an application level protocol message for a 
specific time, an II Dummy message shall be delivered to the counterpart to transfer the turn with the consideration of 
not delaying its transmission of application protocol message. 

7.2.2 11 message Structure and common field encoding 

7.2.2.1 General 

7.2.2.1 .1 Message Header structure 

The II message structure is shown in figure 7.2.2.1. Each II messages consists of two parts, i.e. the first part referred to 
as the II message common part and the second part consisting of zero or more II information elements. The II message 



£75/ 



3GPP TS 24.294 version 9.1.0 Release 9 



36 



ETSI TS 124 294 V9.1.0 (2010-04) 



common part is included in every II message. The II information elements that are included in an II message depend 
on a type of II message being sent. 

The text in this clause describes the content of the II message common part. The octet number 1 (shown at the top of 
the figure 7.2.2.1) is sent first followed by octet 2, 3, etc. Within each octet, the bit designated "bit 1" is transmitted 
first, followed by bits 2, 3, 4, etc. 



8 7 6 5 


4 3 2 1 


Octet 


Protocol version number 


Protocol identifier 


1 


Message type | R | Reason 


2 


Reason 


3 


Call-Identifier (Part-1) 


4 


Call-Identifier (Part-2) 


5 


Call-Identifier {Part-2) 


6 


Sequence-ID 


7 


Information element #1 




Information element #2 



Figure 7.2.2.1 : II message structure 



7.2.2.1.2 



Protocol Version information 



The first octet is divided into two four-bit subfields, i.e. the Protocol identifier and the Protocol version number. The 
Protocol identifier for II protocol is "0001" and indicates that the respective message, transported across the transport- 
layer connection, is an II protocol message. The Protocol version number indicates that this is the first version of this 
specification and the respective value of the Protocol version number subfield is "0001". 



7.2.2.1.3 



Message Type and Reason 



The second octet and third consists of five-bit Message type field that identifies the type of the II message, while the 
ten-bit Reason fields provide additional information about the respective II message, i.e.. Progress reason value, as 
specified in table 7.2.2.1. If the three-bit Message type parameter is set to "00000", it indicates that the Reason field is 
used. If the five-bit Message type parameter is not set to "00000", it indicates that the Reason field is not used and it 
shall be ignored. 



7.2.2.1.4 



Call Identifier 



The three octets (i.e. the octet number 4, 5, and 6) that follow the Reason type field contain the Call-Identifier field. The 
Call-Identifier field uniquely specify the II session across all II interfaces (i.e. between the ICS AS and all ICS UEs 
connected to the ICS AS). The Call-Identifier field is divided into two subfields, i.e. the part-1 subfield consisting of 
one octet and the part-2 subfield consisting of two octets. The part 1 subfield is always filled by the UE, while the part-2 
subfield is always filled by the ICS AS. The part-1 and part-2 subfields are analogous to the SIP tags inserted in the 
From and To header fields. The values of all "0" inserted in the octet 3 (i.e. in the Call-Identifier Part-1) indicates that 
the Call-Identifier (Part-1) subfield is empty (i.e. it has no value). Likewise, values of all "0" inserted in the octet 4 
and 5 (i.e., in the Call-Identifier Part-2) indicates that the Call-Identifier Part-2 subfield is empty (i.e., it has no value). 
When the UE forwards the first II message pertaining to anil session that is being established (e.g., an II Invite or an II 
Progress) to the ICS AS, the UE inserts a new value into the Call-Identifier (Part-1) subfield (i.e., a value that is 
currently not being unused). Likewise, when the ICS AS forwards the first II message pertaining to an II session that is 
being established (e.g., an II Invite or an II Progress) to the UE, the ICS AS inserts a value into the part-2 subfield. 
When inserting a value into the Call-Identifier (Part-2) subfield, the ICS AS has to insure that the resulting Call- 
Identifier field is unique across all II interfaces. For example, the ICS AS, upon receiving the first II message from the 
ICS UE, may insert into the Call-Identifier (Part-2) subfield a value that it is currently using in some other II sessions, 
only if the resulting Call-Identifier field is unique across all II interfaces (i.e. between the ICS AS and all ICS UEs). 



7.2.2.1.5 



Sequence- ID 



The Sequence-ID field value (i.e., the octet number 7) guarantees the proper ordering of the II message. The sender of 
the II message increments the Message sequence number value by one for each new II message forwarded to its peer. 
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The sequence number value is expressible as an 8-bit unsigned integer. Once the count reaches the value of 2**8, it 
wraps around back to one. 



7.3 Messages 

7.3.1 General Messages 

Table 7.3.1 summarizes the messages for II. 



Table 7.3.1 : General Message types 



Message 


Message Type Value (5 bit) 
hex 


Reason Value (10 bit) hex 


11 INVITE (MO) 


0x1 


0x000 


11 INVITE (MT) 


0x1 


0x001 


11 INVITE 
(Augmentation) 


0x1 


0x002 


11 BYE 


0x2 


0x000 


11 REFER 


0x9 


0x000 


11 PROGRESS 


0x00 


0x64 - 0xC7 


11 SUCCESS 


0x00 


0xC8-0x12B 


11 FAILURE 


0x00 


0x12C-0x25E 


11 Dummy 


0x00 


0x3FF 



Editor's Note: the need for the II Dummy message is FFS. 

7.3.2 11 INVITE - ICS UE initiated 
7.3.2.1 General 

This message is sent by the ICE UE to the network to establishment of a session. See table 7.3.2.1. 
Message type: II INVITE 
Direction: ICS UE to SCC AS 

Table 7.3.2.1 : II INVITE message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Protocol Information 


Protocol Information 


M 


V 


1 




7.2.2.1.2 








Message Type 


Request Message - INVITE 
7.2.2.2.1.2 


M 


V 


2 


Call ID 


Call-Id 
7.2.2.1.4 


M 


V 


2 


Message Sequence Number 


Sequence-Id 
7.2.2.1.5 


M 


V 


1 


Timestamp 


Timestamp 
7.3.2.8 


M 


V 


1 


To 


To 
7.3.2.3 


M 


LV 


FFS 


From 


From 
7.3.2.4 


M 


LV 


FFS 


Accept Contact 


Accept Contact 
7.3.2.5 





TLV 


5 


ERAccept Contact 


ERAccept Contact 
7.3.2.6 





TLV 


3-Y 


Reject Contact 


Reject Contact 
7.3.2.7 





TLV 


5 
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7.3.2.2 Message Type 

Identifies that the message is: 

i) a Mobile Originated II INVITE. 

7.3.2.3 To 

This information element shall be included, it identifies the logical identity of the recipient for the request according to 
the procedures specified in RFC 3261 [6]. For the coding of this information element please see subclause 7.4.2.3. 

7.3.2.4 From 

This information element shall be included, it identifies the logical identity that the dialogue originates from according 
to the procedures specified in RFC 3261 [6]. For the coding of this information element please see subclause 7.4.2.3. 

7.3.2.5 Accept Contact 

This information element shall be optionally included, if feature tags are indicated. 

7.3.2.6 ERAccept Contact 

This information element shall be optionally included, if feature tags that have been qualified with the parameter tag 
"explicit" or "require" are indicated. 

7.3.2.7 Reject Contact 

This information element shall be optionally included, if feature tags are indicated. 

7.3.2.8 Timestamp 

This information element shall be included; it provides the SCC AS local time to the ICS UE. 

7.3.3 INVITE - SCC AS initiated 
7.3.3.1 General 

This message is sent by the SCC AS to the ICS UE to establishment of a session. See table 7.3.3.1. 
Message type: II INVITE. 
Direction: SCC AS to ICS UE 
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Table 7.3.3.1 : 11 INVITE message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Protocol Information 


Protocol Information 
7.2.2.1.2 


M 


V 


1 


Message Type 


Request Message - INVITE 
7.2.2.2.2.2 


M 


V 


2 


CalllD 


Call-Id 
7.2.2.1.4 


M 


V 


2 


Message Sequence Number 


Sequence- Id 
7.2.2.1.5 


M 


V 


1 


Timestamp 


Timestamp 


M 


V 


1 


From 


From 
7.3.3.3 


M 


LV 


FFS 


sec AS PSI DN 


sec AS PSI DN 
7.3.3.5 


M 


LV 


3-15 


To 


To 
7.3.3.4 


M 


LV 


FFS 



7.3.3.2 



Message Type 



Identifies that the message is: 

i) a Mobile Terminated II INVITE. 



7.3.3.3 



From 



This information element shall be included; it identifies the logical identity that the dialogue originates from. It is the 
same as that defined in RFC 3261 [6] however no display name is included. For the coding of this information element 
please see subclause 7.4.2.3. 

7.3.3.4 To 

This information element shall be included; it identifies the logical identity of the recipient for the request. It is the same 
as that defined in RFC 3261 [6]. For the coding of this information element please see subclause 7.4.2.3. 

7.3.3.5 sec AS PSI DN 

This information element shall be included; it uniquely identifies the SCC AS and session on that AS. 

7.3.3.6 Timestamp 

This information element shall be included; it provides the SCC AS local time to the ICS UE. 

7.3.4 BYE - ICS UE initiated 
7.3.4.1 General 

This message is sent by the ICS UE to the SCC AS to establishment of a session. See table 7.3.4.1. 
Message type: II BYE 
Direction: ICS UE to SCC AS 
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Table 7.3.4.1 : II BYE message content 



Information 
element 


Type/Reference 


Presence 


Format 


Length 


Protocol Information 


Protocol Information 
7.2.2.1.2 


M 


V 


1 


Message Type 


Request Message - BYE 
7.3.4.2 


M 


V 


2 


CalllD 


Call-Id 
7.2.2.1.4 


M 


V 


2 



7.3.4.2 



Message Type 



Identifies that the message is: 
i) an II BYE. 

7.3.5 BYE - sec AS initiated 
7.3.5.1 General 

This message is sent by the SCC AS to the ICS UE to establish of a session. See table 7.3.5.1. 
Message type: II BYE 
Direction: SCC AS to ICS UE 

Table 7.3.5.1 : II BYE message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Protocol Information 


Protocol Information 
7.2.2.1.2 


M 


V 


1 


Message Type 


Request Message - BYE 
7.3.5.2 


M 


V 


2 


CalllD 


Call-Id 
7.2.2.1.4 


M 


V 


2 



7.3.5.2 Message Type 

Identifies that the message is: 
i) an II BYE. 

7.3.6 11 PROGRESS - ICS UE initiated 
7.3.6.1 General 

This message is sent by the ICE UE to the network to establish of a session. See table 7.3.6.1. 
Message type: II PROGRESS 
Direction: ICS UE to SCC AS 
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Table 7.3.6.1 : II PROGRESS message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Protocol Information 


Protocol Information 


M 


V 


1 




7.2.2.1.2 








Message Type 


Request Message - PROGRESS 
7.3.6.2 


M 


V 


2 


CalllD 


Call-Id 
7.2.2.1.4 


M 


V 


2 


Message Sequence Number 


Sequence- Id 
7.2.2.1.5 


M 


V 


1 



7.3.6.2 



Message Type 



Identifies that the message is 
i) an II PROGRESS. 

7.3.7 11 PROGRESS - SCC AS initiated 
7.3.7.1 General 

This message is sent by the SCC AS to the ICS UE to establish of a session. See table 7.3.3.1. 
Message type: II PROGRESS 
Direction: SCC AS to ICS UE 

Table 7.3.3.1 : II PROGRESS message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Protocol Information 


Protocol Information 


M 


V 


1 




7.2.2.1.2 








Message Type 


Request Message - PROGRESS 
7.3.7.2 


M 


V 


2 


CalllD 


Call-Id 
7.2.2.1.4 


M 


V 


2 


Message Sequence Number 


Sequence-Id 
7.2.2.1.5 


M 


V 


1 


SCC AS PS! DN 


SCC AS PSI DN 
TBD 


M 


LV 


?? 



7.3.7.2 



Message Type 



Identifies that the message is: 
i) an II PROGRESS. 

7.3.8 II FAILURE 



7.3.8.1 



General 



This message is sent by the ICE UE to the network or from the network to the ICS UE to identify that an error has 
occured. See table 7.3.8.1. 

Message type: II Failure 

Direction: ICS UE to SCC AS and SCC AS to ICS UE 
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Table 7.3.8.1 : 11 Failure message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Protocol Information 


Protocol Information 


M 


V 


1 




7.2.2.1.2 








Message Type 


Request Message - INVITE 
7.3.8.2 


M 


V 


2 


Call ID 


Call-Id 
7.2.2.1.4 


M 


V 


2 


Message Sequence Number 


Sequence-Id 
7.2.2.1.5 


M 


V 


1 


To 


To 
7.3.8.3 





TLV 


FFS 


Reason Phrase 


Phrase 





TLV 





7.3.8.2 Message Type 

Identifies that the message is: 
i) an II FAILURE. 



7.3.8.3 



To 



This information element may optionally be included and can appear multiple times. It identifies alternative address"s 
that the UE should attempt to use It is the same as the contact header field that is defined in sections 21.3 of 
RFC 3261 [6]. 



7.3.8.4 



Reason Phrase 



This information element may optionally be included and can appear multiple time. It is the same as the Reason-Phrase 
header field that is defined in RFC 3261 [6]. 



7.4 



11 information elements and functional definition 



7.4.1 II information elements 

The list of the II information elements is shown in table 7.4.1. 

Editor"s Note: The list of II information elements is not complete. 

Table 7.4.1 II -information elements 



11 information element 
Name 


Description and 

content 

(subclauses) 


Error-code 


7.4.2.2 


Identity Information 


7.4.2.3 


Privacy 


7.4.2.4 


SCC-AS-id 


7.4.2.5 


Session-identifier 


7.4.2.6 


Replaces 


7.4.2.8 


Accept Contact 


7.3.2.5 


ERAccept Contact 


7.3.2.6 


Reject Contact 


7.3.2.7 


Mid-Call 


7.4.2.12 


Reason Phrase 


7.4.2.13 


Timestamp 


7.4.2.14 



Error-code 
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The Error-code information element is included in every Il-Error response message. The Error-code information 
element is binary encoded SIP failure response. The SIP 4xx request failure responses, the 5xx server failure responses, 
and the 6xx global failure responses are binary encoded and included in the Error-code information element as specified 
in subclause 7.4.2.1 and table 7.4.2.1. The interpretation of each binary encoded failure response is analogous to the 
interpretation of associated SIP failure response. 

Identity Information 

The Identity Information IE specifies a public user identity e.g. 

i) the identity of the calling user, e.g., the calling party number, either as an E. 164, Identifier or a SIP URL 

ii) the identity of the called user, e.g., the called party number. 

The Identity information element may contain either an E.164, a SIP URI or a identifier that identifies a public user 
identity to be used (see annex A). The position of the information element in the message and direction it was received 
in identifies if the element is the calling or called parties identity. 

Privacy 

The UE uses the Privacy information element to indicate to the SCC AS how to handle the SIP header fields when the 
sec AS forwards the SIP requests and responses on behalf of the UE to the far-end UA. The Privacy information 
element when sent by the UE to the SCC AS contains binary encoded "priv-value" (as specified in the RFC 3323 [8] 
and RFC 3325 [9]). When the SCC AS, upon receiving a Privacy information element over II interface, forwards a SIP 
request or a response to the far-end UA, the SCC AS behaves as specified in the RFC 3323 [8] and RFC 3325 [9] e.g. 
the SCC AS inserts a P-Asserted-Identity header field into SIP message as requested by the Privacy information 
element. 

SCC-AS-id 

The SCC-AS-id information element contains an International E. 164 number representation of the SCC AS PSI DN that 
points to the SCC AS. When the UE sets up a CS bearer connection by sending a SETUP message to the MSC server, 
the UE specifies the respective International E.164 number as the called party number. Subsequently the call will be 
routed to the respective SCC AS via a MGCF where the SCC-AS-PSI-DN will be treated as a wildcard PSI as specified 
in 3GPP TS 23.003 [15] and procedures as specified in 3GPP TS 24.229 [12] subclause 5.3,2.1 item 3. 

Session-identifier 

The Session-identifier information element is an identifier used either by the UE or the SCC AS to uniquely and 
globally identify a II session across all interface (i.e. the II interface, Gm interface and the IMS). The Session identifier 
is dynamically allocated by the SCC AS to identify the II session that is being established. The SCC AS includes the 
Session-identifier information element in the first II message sent by the SCC AS to the UE. The Session-identifier 
information element may contain different values, e.g. the Session Transfer Identifier (STI), as specified in 
subclause 7.4.2.1 and associated subclause 7.4.2.1. 

Replaces 

The Replaces information element is used by the UE to identify an existing call or a SIP dialog that will be replaced 
with an II session being established over the II interface. When the UE wants to replace an existing call or a SIP dialog 
with a new II session, the UE sends an II Invite request message to the SCC AS with the Replaces information element 
that contains the identity of the SIP dialog or a call that will be replaced with a new call being established. In the case of 
UE assisted T-ADS, the SCC AS may send an II Invite request message to the terminating ICS UE with Replaces 
information element that contains the identity of the SIP dialog to change the service control for the session from Gm to 
II. 

Accept Contact 

The Accept contact information element is used by the UE to identify the SIP feature tags that the UE are included in a 
SIP Accept Contact header per procedures in RFC 3841 [14]. However if the feature tags are to be appended with 
"explicit" and or the "require" parameter tags then the SIP feature tag shall not be sent in the Accept Contact but in the 
ERAccept Contact header information element. 

ERAccept Contact 



£75/ 



3GPP TS 24.294 version 9.1.0 Release 9 



44 



ETSI TS 124 294 V9.1.0 (2010-04) 



The ERAccept contact information element is used by the UE to identify those SIP feature tags that either "explicit" or 
"require" parameter tags added per procedures in RFC 3841 [14]. If "explicit" and or "require" parameter tag is required 
then the feature tag is not included in the Accept Contact information element. 

Reject Contact 

The Reject contact information element is used by the UE to identify the SIP feature tags that the UE would normally 
send in a SIP Reject contact header per procedures in RFC 3841 [14]. 

Mid-Call 

The Mid-Call information element is used between ICS UE and the SCC AS to exchange the Mid-call supplementary 
services control information, e.g. hold, resume, conference. 

Timestamp 

The Timestamp information element specifies a local time on the II message sender. The local time is measured in 
seconds and it is 32 bits long. 



7.4.2 11 Information elements encoding 
7.4.2.1 General 

The structure of the II information elements is shown in figure 7.4.2.1. 



8 7 6 5 4 


3 2 1 


Octet 


Information Element code 


Code specific 


1 


Information Element length (in octets) 


2 


Information Element body (as required) 


3 


etc. 









Figure 7.4.2.1 : II information element format 

Each II information element contains a common two-octet field followed by a variable-size body. The first octet 
contains the Information Element code and Code specific values. Each II information element is uniquely identified 
with the respective Information Element code (i.e., encoded with bits numbered 4, 5, to 8 of the first octet). The Code 
specific value (i.e., encoded with bits numbered 1, 2, and 3 of the first octet) provide additional information about 
respective II information element. For example, if the Information Element code specifies that this is a To-id II 
information element, then the Code specific value will indicate whether the Information Element body contains an 
E.164 number or SIP URL The Code specific values for each respective II information element are described in the 
respective subclauses. 

The second octet i.e. the Information Element length specifies the length of the II information element body (i.e., the 
number of octets following the Information Element length) in binary format. The bit number 1 of octet number 2 is the 
list significant bit and bit number 8 of the octet number 2 is the most significant bit. The table 7.4.2.1 specifies the 
Information Element code for each II information element. 



Table 7.4.2.1 : II -information element coding 



Information 
Element code 


11 information element 
Name 


Reference 
subclause 


Bits 
87654 






10001 


Error-code 


7.4.2.2 


10011 


Identity Information 


7.4.2.3 


10 100 


Privacy 


7.4.2.4 


10 101 


SCC-AS-id 


7.4.2.5 


10 110 


Session-identifier 


7.4.2.6 


10010 


Replaces 


7.4.2.8 


11000 


Mid-Call 


7.4.2.12 


11001 


Timestamp 


7.4.2.14 
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7.4.2.2 



Error-code 



Editor" s Note: How and which additional waning-codes and reason-values are encoded and included in the Error- 
code information element is FFS. 



7.4.2.3 



Identity Information 



The purpose of the Identity Information information element is to transport a public identity e.g. To party, From Party 
etc. The Identity Information information element may contain either a SIP URI or a telephone number (e.g. 
international number, national number) or an identifier value that identifies a known public identity. The Code specific 
field, i.e., the bits 3, 2, and 1 of the octet number 1 specify the type of information contained in the Identity Information 
information element,. 

If the Identity Information is a SIP URI username@domainname then the Code specific fields bits 3,2, and 1 shall be set 
to "010" and shall be encoded to an octet string according to UTF-8 encoding rules as specified in RFC 3629 [16]. 

If the Identity Information to be used by is a tel URI or a SIP URI with URI parameter Usei-Phone then the Code 
specific field, i.e., the bits 3, 2, and 1 of the octet number 1 is set to "001" it indicates that the Identity Information 
information element contains an E.164 number (see table 7.4.2.3.1-2). When the Identity Informationinformation 
element contains an International number (i.e. an E.164 number), the E.164 digit-string is included in the octet 3, octet 
4, octet 5, etc. as follows: 

the bits numbers 8, 7, 6, and 5 of octet number 3 are used to binary encode the most significant digit of the E. 164 
digit-string; 

the bits numbers 4, 3, 2, and 1 of octet number 3 are used binary encode the next significant digit of the E.164 
digit- string; 

the bits numbers 8, 7, 6, and 5 of octet number 4 are used binary encode the next significant digit of the E. 164 
digit-string; and so on until the entire E.164 digit-string is included in the From-id information element; and 

the bit-pattern "11 IT'iserted either in the bits 8, 7, 6, and 5 or bits 4, 3, 2, and 1 of any octet indicates the end of 
the E.164 digit-string, i.e. the bit-pattern of "1111" is used as the end-delimiter for the E.164 digit-string. 

Table 7.4.2.3.1-1: Identity Information information element 



8 


7 6 5 4 


3 2 1 


Octet 


1 
1 


Information Element code 


1 


Code specific 


1 


Information Element length (in octets) 


2 


Information Element body 


3 


etc. 



Table 7.4.2.3.1-2: From-id information element 



(octet 1) Code specific 


Bits 


321 




000 


Unspecified 


001 


International number, i.e. E.164 number (Note 1) 


010 


SIP URI 


01 1 


Identifier (See Annex A) 




Other values are reserved for future use 


(octet 3) 


SIP URI 




The URI shall be encoded to an octet string according to UTF-8 encoding rules as 
specified in RFC 3629 [16] 
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(octet 3) 


Identifier 




Contains one octet body coded with identifier value that identifies the public user 
identity. 


(octet 3) 


Bits 


8765 


the most significant digit of the E.164 digit-string 


(octet 3) 


Bits 


4321 


the next significant digit of the E. 164 digit-string (Note 2) 


(octet 4) 


Bits 


8765 


the next significant digit of the E. 164 digit-string (Note 2) 


(octet 4) 


Bits 


4321 


the next significant digit of the E. 1 64 digit-string (Note 2) 


(next octet) 


Bits 

(Note 2) 


(Note 3) 


Note 1 - Prefix or escape digits shall not be included. 

Note 2 - the next significant digits of the E. 164 digit-string are included in subsequent bits 8, 7, 6, and 5 or 
bits 4, 3, 2. 

Note 3 -The E. 164 digit-string terminates with delimiter "1111" in the bits 8, 7, 6, and 5 orbits 4, 3, 2, 
and 1 of any octet indicating the end of the E. 164 digit-string. 



7.4.2.4 



Privacy 



The ICS UE may include the Privacy information element in the II Invite message to indicate its privacy preferences 
that the SCC AS should apply to the SIP session toward the remote UE. When the SCC AS sets up a SIP session on 
behalf of the UE, the SCC AS sends a SIP INVITE request that includes the privacy information that the SCC AS 
received in the Privacy information element. 

The Privacy information element when sent by the ICS UE to the SCC AS contains binary encoded "priv-value" (with 
the same semantics as specified in the RFC 3323 [8] and RFC 3325 [9]). The UE may request multiple types of privacy 
for the same call (see RFC 3323 [8]). Hence, the UE include all of the requested privacy types in its Privacy information 
element by setting the respective bits as shown in table 7.4.2.4.1. 



8 7 6 5 4 


3 2 1 


Octet 


Information Element code 
1 1 



Code specific 




1 


Information Element length (in octets) 


2 


Information Element body 


3 









Figure 7.4.2.4.1 : Privacy information element 
Table 7.4.2.4.1 : Privacy information element 



(octet I) 
Bits 
321 
001 



Code specific 



(NOTE 1) 
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Other values are reserved for future use 



(octet 3) 

Bits 
1 


Bit 7 
1 


Bit 6 
i 


Bits 
1 


Bit 4 
1 


Bits 


1 



The UE indicates to the SCCAS that "Privacy: id" (as specified in the RFC 3325 [9]) is 
requested (NOTE 2). 

The UE indicates to the SCCAS that "Privacy: header" (as specified in the RFC 3323 [S]) 
is requested (NOTE 2) 

The UE indicates to the SCCAS that "Privacy: session" (as specified in the 
RFC 3323 [S]) is requested (NOTE 2) 

The UE indicates to the SCCAS that "Privacy: user" (as specified in the RFC 3323 [S]) is 
requested (NOTE 2) 

The UE indicates to the SCCAS that "Privacy: none" (as specified in the RFC 3323 [S]) 
is requested (NOTE 2) 



The UE indicates to the SCCAS that "Privacy: critical" (as specified in the 
RFC 3323 [S]) is requested (NOTE 2) 



Bits 2 and 1 reserved for future use 



NOTE 1 : If the Code specific value is set to "001" it indicates that the Privacy information element consists of three 

octets and each bit in octet number 3 is interpreted as specified in this table. 
NOTE 2: The value of "0" in this bit indicates that corresponding "priv-value' (with the same semantics as specified in 
the RFC 3323 [8] and RFC 3325 [9]) is not used and respective privacy is not requested. 



7.4.2.5 SCC-AS-id 

The SCC-AS-id information element contains an International E. 164 Number representation of the SCC AS PSI DN 
that points to the SCC AS. The SCC AS PSI DN information element has a minimum length of 3 octets and a maximum 
length of 10 octets. 

The SCC-AS-id information element may contain either a SIP URI or an international telephone number (i.e. an E. 164 
national number). The Code specific field, i.e., the bits 3, 2, and 1 of the octet number 1 in figure 7.4.2.5.1 specify the 
type of information that is used to identify the SCC AS. When the SCC AS forwards a PSI DN associated with the SCC 
AS to the UE, the SCC AS will include the PSI DN in the SCC-AS-id information element. The PSI DN is an E.164 
number. 

Editor"s Note: How to include non-international numbering plans, SIP URI, and SIP URI with user=phone into the 
From-id information element is FFS. 

When the Code specific field, i.e., the bits 3, 2, and 1 of the octet number 1 is set to "001" it indicates that the SCC-AS- 
id information element contains a PSI DN (i.e. an E.164 number). When the SCC-AS-id information element contains a 
PSI DN (i.e. an E.164 number), the E.164 digit-string is included in the octet 3, octet 4, octet 5, etc. as shown in 
table 7.4.2.5.1. 
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8 


7 6 5 4 


3 2 1 


Information Element code 
1 1 
1 


Code specific 


Information Element length (in octets) 


Information Element body 



Octet 

1 



2 

3 

etc. 



Figure 7.4.2.5.1 : SCC-AS-id information element 
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Table 7.4.2.5.1 : SCC-AS-id information element 



(octet 1) 


Code specific 


Bits 




321 




000 


Unspecified 


001 


PSI DN, i.e. E.164 number (Note 1) 




Other values are reserved for future use 


(octet 3) 




Bits 




8765 


the most significant digit of the E. 164 digit-string 


(octet 3) 




Bits 




4321 


the next significant digit of the E. 164 digit-string (Note 2) 


(octet 4) 




Bits 




8765 


the next significant digit of the E. 164 digit-string (Note 2) 


(octet 4) 




Bits 




4321 


the next significant digit of the E. 164 digit-string (Note 2) 


(next octet) 




Bits 






(Note 3) 


Note 1 - Prefix 


or escape digits shall not be included. 


Note 2 - the next significant digits of the E. 164 digit-string are included in subsequent bits 8, 7, 6, and 5 or 


bits 4, 3, 2. 




Note 3 - The E. 164 digit-string terminates with delimiter " 1 1 11" in the bits 8, 7, 6, and 5 or bits 4, 3, 2, 


and 1 of any octet indicating the end of the E. 164 digit-string. 



7.4.2.6 



Session-identifier 



The Session-identifier information element is used either by the ICS UE or the SCC AS to covey the identity of the 
session being established. The Code specific subfield, i.e., the bits 3, 2, and 1 of the octet number 1 specify the type of 
information that is used to identify the session across. 

When a SIP dialog or an 11 session is identified with an E.164 number (e.g. with a STl), then this identifier is conveyed 
across the II interface in a Session-identifier information element. In this case, the Code specific field, i.e., the bits 3, 2, 
and 1 of the octet number 1 is set to "001", as shown in figure 7.4.2.6.1 and table 7.4.2.6.1. 

Editor's Note: How to include a SIP dialog identifier (i.e. the From tag, the To tag, and the Call-ID into the Session- 
identifier information element is FFS. 



Octet 

1 



8 


7 6 5 4 


3 2 1 


Information Element code 
1 1 
1 


Code specific 


Information Element length (in octets) 


Information Element body 



2 

3 

etc. 



Figure 7.4.2.6.1 : Session-identifier information element 
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Table 7.4.2.6.1 : Session-identifier information element 



(octet I) 
Bits 
321 
000 
001 



Code specific 



Unspecified 

Session or a dialog identified with an E.164 number (Note 1) 

Other values are reserved for future use 



(octet 3) 
Bits 
8765 



the most significant digit of the E.164 digit-string 



(octet 3) 

Bits 

43 2 1 the next significant digit of the E.164 digit-string (Note 2) 



(octet 4) 

Bits 
8765 



the next significant digit of the E. 164 digit-string (Note 2) 



(octet 4) 

Bits 

43 2 1 the next significant digit of the E.164 digit-string (Note 2) 

(next octet) 

Bits 

(Note 3) 
Note 1 - Prefix or escape digits shall not be included. 

Note 2 - the next significant digits of the E. 164 digit-string are included in subsequent bits 8, 7, 6, and 5 or 
bits 4, 3, 2. 

Note 3 - The E. 164 digit-string terminates with delimiter "1111" in the bits 8, 7, 6, and 5 or bits 4, 3, 2, 
and 1 of any octet indicating the end of the E. 164 digit-string. 



7.4.2.7 



Void 



7.4.2.8 



Replaces 



The Replaces information element is included in the II Invite message to indicate to the recipient that the II session 
being established will replace the existing SIP dialog identified by the Replaces information element. The Replaces 
information element also contains the identity of the dialog that will be replaced. 



8 



1 



Information Element code 
10 10 


Code specific 


Information Element length (in octets) 











Figure 7.4.2.8.1 : Replaces information element 



Octet 

1 

2 
3 
4 



Table 7.4.2.8.1 : Replaces information element 



(octet I) 
Bits 
321 
000 
001 



Code specific 



Unspecified 

The Code specific value set to "001" Specifies that the SIP dialog that will be replaced is 

identified with a STI that is an E.164 number. (NOTE 1) 
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Other values are reserved for future use 



(octet 3) 
Bits 
8765 



the most significant digit of the E.164 digit-string 



(octets) 
Bits 
4321 



the next significant digit of the E. 164 digit-string (NOTE 2) 



(octet 4) 
Bits 
8765 



the next significant digit of the E.164 digit-string (NOTE 2) 



(octet 4) 
Bits 
4 3 2 1 the next significant digit of the E. 164 digit-string (NOTE 2) 

(next octet) 
Bits 

(NOTE 3) 
NOTE 1 : Prefix or escape digits shall not be included. 
NOTE 2: The next significant digits of the E.1 64 digit-string are included in subsequent bits 8, 7, 6, and 5 or 

bits 4, 3, 2. 
NOTE 3: The E.1 64 digit-string terminates with delimiter "1111 " either in the bits 8, 7, 6, and 5 or bits 4, 3, 2, and 1 of 
any octet, hence indicating the end of the E.1 64 digit-string. 



7.4.2.9 Accept Contact 

The UE may include the Accept Contact element in the II Invite message to indicate any called feature preferences per 
RFC 3841 [14]. 

Table 7.4.2.9-1 : Accept Contact information element 



8 


7 6 5 4 


3 2 1 


Octet 


1 
1 


Information Element code 

1 


Code specific 


1 


Information Element length (in octets) 


2 


Information Element body 


3 


..5 



Table 7.4.2.9-2: Accept Contact information element Octets mapping 



(octet 3) 



Bit Specific 



Bits 



sip.audio as defined in RFC 3840 [15] 



sip.application as defined in RFC 3840 [15] 



sip.data as defined in RFC 3840 [15] 



sip.control as defined in RFC 3840 [15] 



sip.video as defined in RFC 3840 [15] 



sip.text as defined in RFC 3840 [15] 



sip.automata as defined in RFC 3840 [15] 



sip.duplex ^ full as defined in RFC 3840 [15] 
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Table 7.4.2.9-3: Accept Contact information element Octet4 mapping 



(octet 4) Bit Specific 



Bits 



sip.duplex ^ half, as defined in RFC 3840 [15] 



sip.duplex = receive only as defined in RFC 3840 [15] 



sip.duplex = send only as defined in RFC 3840 [15] 



sip.mobility - fixed as defined in RFC 3840 [15] 



sip.mobility - mobile as defined in RFC 3840 [15] 



sip.actor ^principal, as defined in RFC 3840 [15] 



sip.actor =:attendant, as defined in RFC 3840 [15] 



sip.actor = msg-taker, as defined in RFC 3840 [15] 



Table 7.4.2.9-4: Accept Contact information element Octets mapping 



(octet 5) 



Bit Specific 



Bits 



sip.actor - information as defined in RFC 3840 [15] 



sip.isfocus as defined in RFC 3840 [15] 



sip.byeless as defined in RFC 3840 [15] 



sip.rendering - yes as defined in RFC 4235 [16] 



sip.rendering - no as defined in RFC 4235 [16] 



sip.rendering - unknown as defined in RFC 4235 [16] 



sip.message as defined in RFC 4569 [17] 



sip.ice 



Table 7.4.2.9-5: Accept Contact information element Octets mapping 



(octet 6) Bit Specific 


Bits 


1 


Reserved 


2 


Reserved 


3 


Reserved 


4 


Reserved 


5 


Reserved 


6 


Reserved 


7 


Reserved 


8 


Extension 



7.4.2.1 ERAccept Contact 

The UE may include the ERAccept Contact element in the II Invite message to indicate any called feature preferences 
per RFC 3841 [14] that require the "explicit" and or "require" parameter tag appended to them.. 

Table 7.4.2.10-1 : ERAccept Contact information element 



8 


7 


6 1 5 1 4 


3 2 1 


Octet 


Information Element code 
10 10 


Code specific 


1 


Information Element length (in octets) 


2 


E 


R 


Feature Tag Value 


3-Y. 
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Table 7.4.2.10-2: ERAccept Contact information element Feature Tag coding 



(octet 3-Y) 


Code specific 


Bit 


8 


Value 1 "explicit' required as defined in RFC 3841 [14] 


7 


Value 1 "require' required, as defined in RFC 3841 [14] 


6-1 


Feature Tag 



(octet -3-Y) Bit Specific 



Bits 



654321 



000000 



sip.audio as defined in RFC 3840 [15] 



000001 



sip.application as defined in RFC 3840 [15] 



000010 



sip.data as defined in RFC 3840 [15] 



00001 1 



sip.control as defined in RFC 3840 [15] 



000100 



sip.video as defined in RFC 3840 [15] 



000101 



sip.text as defined in RFC 3840 [15] 



0001 10 



sip.automata as defined in RFC 3840 [15] 



0001 1 1 



sip.duplex ^ full as defined in RFC 3840 [15] 



001000 



sip.duplex = half, as defined in RFC 3840 [15] 



001001 



sip.duplex = receive only as defined in RFC 3840 [15] 



001010 



sip.duplex - send only as defined in RFC 3840 [15] 



001011 



sip.mobility - fixed as defined in RFC 3840 [15] 



001100 



sip.mobility - mobile as defined in RFC 3840 [15] 



001101 



sip.actor =: principal, as defined in RFC 3840 [15] 



001110 



sip.actor - attendant, as defined in RFC 3840 [15] 



001111 



sip.actor -= msg-taker, as defined in RFC 3840 [15] 



010000 



sip.actor - information as defined in RFC 3840 [15] 



010001 



sip.isfocus as defined in RFC 3840 [15] 



010010 



sip.byeless as defined in RFC 4235 [16] 



010011 



sip.rendering - yes as defined in RFC 4235 [16] 



010100 



sip.rendering =no as defined in RFC 4235 [16] 



010101 



sip.rendering - unknown as defined in RFC 4235 [16] 



010110 



sip.message as defined in RFC 4569 [17] 



010111 



sip.ice 



01 1 
to 
1 1 1 



000 



1 1 1 



Reserved 



7.4.2.11 Reject Contact 

The UE may include the Reject Contact element in the II Invite message to indicate any called feature preferences per 
RFC 3841 [15]. 

Table 7.4.2.11-1 : Reject Contact information element 



8 


7 6 5 4 


3 2 1 


Octet 


1 


Information Element code 

10 1 


Code specific 


1 


Information Element length (in octets) 


2 


Information Element body 


3 


..5 
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Table 7.4.2.11-2: Reject Contact information element Octets mapping 



(octet 3) Bit Specific 



Bits 



sip.audio as defined in RFC 3840 [15] 



sip.application as defined in RFC 3840 [15] 



sip.data as defined in RFC 3840 [15] 



sip.control as defined in RFC 3840 [15] 



sip.video as defined in RFC 3840 [15] 



sip.text as defined in RFC 3840 [15] 



sip.automata as defined in RFC 3840 [15] 



sip.duplex ^ full as defined in RFC 3840 [15] 



Table 7.3.2.11-3: Reject Contact information element Octet4 mapping 



(octet 4) 



Bit Specific 



Bits 



sip.duplex = half, as defined in RFC 3840 [15] 



sip.duplex - receive only as defined in RFC 3840 [15] 



sip.duplex - send only as defined in RFC 3840 [15] 



sip.mobility = fixed as defined in RFC 3840 [15] 



sip.mobility = mobile as defined in RFC 3840 [15] 



sip.actor ^principal, as defined in RFC 3840 [15] 



sip.actor -attendant, as defined in RFC 3840 [15] 



sip.actor - msg-taker, as defined in RFC 3840 [15] 



Table 7.3.2.11-4: Reject Contact information element Octets mapping 



(octet 5) 



Bit Specific 



Bits 



sip.actor - information as defined in RFC 3840 [15] 



sip.isfocus as defined in RFC 3840 [15] 



sip.byeless as defined in RFC 4235 [16] 



sip.rendering - yes as defined in RFC 4235 [16] 



sip.rendering - no as defined in RFC 4235 [16] 



sip.rendering - unknown as defined in RFC 4235 [16] 



sip.message as defined in RFC 4569 [17] 



sip.ice 



Table 7.3.2.11-4: Reject Contact information element Octets mapping 



(octet 6) Bit Specific 


Bits 


1 


Reserved 


2 


Reserved 


3 


Reserved 


4 


Reserved 


5 


Reserved 


6 


Reserved 


7 


Reserved 


8 


Extension 
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7.4.2.12 



Mid-Call 



The Mid-Call information element is used either by the ICS UE or the SCC AS to covey the supplementary services 
control information. The Code specific subfield, i.e., the bits 3, 2, and 1 of the octet number 1 specify the type of 
information that is used to identify the services control type. 

Octet 

1 



2 

3 

etc. 



8 


7 6 5 4 


3 2 1 


Information Element code 
1 1 
1 


Code specific 


Information Element length (in octets) 


Information Element body 



Figure 7.4.2.12.1: Mid-Call information element 



7.4.2.13 Reason-Phrase 

The purpose of the Reason-Phrase field is as defined in RFC 3261 [6]. 

The information element body shall be encoded to an octet string according to UTF-8 encoding rules as specified in 
RFC 3629 [16] 



8 


7 6 5 4 


3 2 1 


Octet 


1 


Information Element code 

10 


Code specific 



1 


Information Element length (in octets) 


2 


Information Element body 


3-Y 



Figure 7.4.2.13.1: Reason-Phrase information element 



7.4.2.14 Time Stamp 

The Timestamp information element is used by the ICS UE and the SCC AS to convey local time. The Timestamp 
information element contains local time measured in seconds. 

When the Code specific field, i.e., the bits 3, 2, and 1 of the octet number 1 is set to "001", as shown in figure 7.4.2.14.1 
and table 7.4.2.14.1, it indicates that the Timestamp information element contains local time measured in seconds in 32 
bits format. The time is conveyed across the II interface in a Timestamp information element. 

Octet 

1 

2 

3 

etc. 



Figure 7.4.2.14.1 : Timestamp information element 
Table 7.4.2.14.1 : Timestamp information element 



8 


7 6 5 4 


3 2 1 


1 


Information Element code 

10 1 


Code specific 


Information Element length (in octets) 


Information Element body 



(octet 1) 


Code specific 


Bits 




321 




000 


Unspecified 


001 


Timestamp (Note 1) 




Other values are reserved for future use 



(octet 3) 
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Bits 



1 



8 765 43 2 the first (right) 8 bits of the Timestamp 



(octet 4) 

Bits 

8 7 6 5 4 3 2 the next 8 bits of the Timestamp 
1 



(octet 5) 

Bits 

8 7 6 5 4 3 2 the next 8 bits of the Timestamp 
1 



(octet 6) 

Bits 

8 7 6 5 4 3 2 the next 8 bits of the Timestamp 
i 

Note 1 - Timestamp in 32 bits format. 



7.5 Session states and Session control procedures 

7.5.1 General 

This clause defines the basic session control states that an individual session may acquire. Since several sessions may 
exist simultaneously across the II interface and each session may be in a different state, the session states describe the 
state of a particular session rather then describing the state of the II interface. The procedures for session control are 
given in subclause 7.5.3. 

7.5.2 Session states 



7.5.2.1 



Session originated by the ICS UE 



7.5.2.1 .1 Session states at ICS UE - ICS UE originated call 

This subclause lists the session states that may exist at the UE for a session originated by the ICS UE. 

null: No session exists. 

trying: This state exists for an UE originated session, when the ICS UE has requested a session establishment by 
sending an Illnvite message but has not yet received any response. 

proceeding: This state exists for an UE originated session when the ICS UE has received an II Progress 
message with Progress reason set to Call progressing from the SCC AS acknowledging that the SCC AS has 
received the II Invite message. 

alerted: This state exists for an UE originated session when the calling ICS UE has received an II Progress 
message with Progress reason set to Ringing indicating that remote endpoint alerting has been initiated. 

confirmed: This state exists for an UE originated session when the ICS UE has received an II Success message 
indicating that the remote endpoint has accepted the session. 

7.5.2.1 .2 Session states at SCC AS - ICS UE originated call 

This subclause lists the II session states that may exist at the SCC AS for a II session originated by the ICS UE. 
null: No II session exists. 
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initiated: This state exists for an UE originated II session when the SCC AS has received an II Invite message 
but has not yet responded. 

progressing: This state exists for an UE originated II session when the SCC AS has sent an II Progress message 
with Progress reason set to Call progressing acknowledging that the SCC AS has received the Illnvite message. 

alerting: This state exists for an UE originated II session when the SCC AS has sent an II Progress message 
with Progress reason set to Ringing indicating that remote endpoint alerting has been initiated. 

confirmed: This state exists for an UE originated II session when the SCC AS has sent an II Success message 
indicating that the II session has been accepted. 

7.5.2.2 Session terminated at the ICS UE 

7.5.2.2.1 Session states at UE - ICS UE terminated call 

This subclause lists the II session states that may exist in the UE for all session terminated at the ICS UE. 

null: No II session exists. 

initiated: This state exists for a II session terminated at the UE when the ICS UE has received an Illnvite 
message but has not yet responded. 

progressing: This state exists for all session terminated at the UE when the ICS UE has sent an II Progress 
message with Progress reason set to Call progressing acknowledging that the ICS UE has received the Illnvite 

message. 

alerting: This state exists for a II session terminated at the UE when the ICS UE has sent an II Progress 
message with Progress reason set to Ringing indicating that local alerting has been initiated but the offered call 
has not yet answered. 

confirmed: This state exists for all session terminated at the UE when the ICS UE has sent an II Success 
message indicating that the II session has been accepted. 

7.5.2.2.2 Session states at SCC AS - ICS UE terminated session 

This subclause lists the session states that may exist in the UE for a session terminated at the ICS UE. 

null: No session exists. 

trying: This state exists for a session terminated at the ICS UE when the SCC AS has requested a session 
establishment by sending an II Invite message but has not yet received a response. 

proceeding: This state exists for a session terminated at the ICS UE when the SCC AS has received an II 
Progress message with Progress reason set to Call progressing from the UE acknowledging that the ICS UE has 
received the Illnvite message. 

alerted: This state exists for an UE terminated session when the SCC AS has received an II Progress message 
with Progress reason set to Ringing indicating that the UE has initiated local alerting. 

confirmed: This state exists for a session terminated at the UE when the SCC AS has received an II Success 
message indicating that the ICS UE has accepted the session. 

7.5.2.3 Session release 
7.5.2.3.1 Session states at ICS UE 

This subclause lists the session states that may exist at the UE for a session released either by the ICS UE or SCC AS. 

release-requested: This state exists when the ICS UE has requested the SCC AS to clear the session by sending 
an II Bye message and the CS bearer has not been cleared using receipt of a DISCONNECT message, in 
accordance with 3GPP TS 24.008 [3]. Upon determining that the CS bearer has cleared using a DISCONNECT 
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message or determining that a II Success message was received, the UE transits to a "null" state. The ICS UE 
attempts to clear the CS bearer if a retransmission timer fires as specified in subclause 6.2.3. 1 .2. 

release-indication: This state exists when the ICS UE has received an II Bye message from the SCC AS 
requesting the UE to clear the session. Per subclause 6.2.3.1.2, upon subsequent clearing the CS bearer using a 
DISCONNECT message, in accordance with 3GPP TS 24.008 [3], or upon subsequent sending of an II Success 
message, the ICS UE transits to a "null" state. 

Editor"s Note: the name and length of the retransmission timer is FFS. 

7.5.2.3.2 Session states at SCC AS 

This subclause lists the session states that may exist at the SCC AS for a session released either by the ICS UE or SCC 
AS. 

release-requested: This state exists when the SCC AS has requested the ICS UE to clear the session by sending 
an II Bye message and the CS bearer has not been cleared. Upon determining that the CS bearer has cleared 
using a DISCONNECT message, in accordance with 3GPP TS 24.008 [3] and 3GPP TS 24.292 [5] or 
determining that a II Success message was received, the SCC AS transits to a "null" state. The SCC AS attempts 
to clear the CS bearer if a retransmission timer fires as specified in 3GPP TS 24.292 [5]. 

release-indication: This state exists when the SCC AS has received an IlBye message from the ICS UE 
requesting the SCC AS to clear the session. Upon subsequent clearing the CS bearer using a SIP BYE request 
sent towards the MGCF or upon subsequent sending of an II Success message in accordance with 
3GPP TS 24.292 [5], the SCC AS transits to a "null" state. 

Editor"s Note: the name and length of the retransmission timer is FFS. 

7.5.3 Session control procedures 

7.5.3.1 General 

Before the II session establishment procedures are invoked, a transport-layer connection must be established between 
the ICS UE and the SCC AS. 

7.5.3.2 Session establishment 

Editor"s Note: The II protocol error cases are not considered in this subclause. The II protocol error cases must be 
considered. 

7.5.3.2.1 UE-originating case 

7.5.3.2.1 .1 Procedure at ICS UE 

7.5.3.2.1.1.1 Session request 

The ICS UE initiates II session establishment procedure by sending an II Invite message to the SCC AS across the II 
interface. The II Invite message shall contain the II information elements as specified in subclause 6.2.1.2.1. Following 
the transmission of the II Invite message the II session shall transit to the "trying" state. When the II session identified 
by the Call-ID (see subclause 7.2.2.1.4) enters the "trying" state, the ICS UE sets timer F to fire in T3 seconds. 

If an unreliable transport-layer connection between the ICS UE and the SCC AS is used, the ICS UE sets timer E to fire 
in Tl seconds. For reliable transport-layer connection timer E is not used. If timer E fires while the II session is still in 
the "trying" state, the original II Invite message (with the same Call-ID and sequence number) is retransmitted and the 
timer E is reset to value of MIN(2*T1, T2). If the timer E fires again, the original II Invite message (with the same 
sequence number) is retransmitted again and the timer E is reset to a MIN (4*T1, T2). This process continues so that 
retransmissions occur with an exponentially increasing interval that caps at T2. 

NOTE 1: Since the values for the timers Tl, T2 and T3 depend on the technology that is used to implement the 

transport-layer connection (e.g. USSD), the values for the timers Tl, T2 and T3 will be specified for each 
technology. 
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If timer F fires while the session is still in the "trying" state, the sessioncall establishment has failed, and the ICS UE 
clears the II session, as described in subclause 6.2.3. In addition, if an unreliable transport-layer connection between the 
UE and the SCC AS is used the, the ICS UE disables timer E. 

7.5.3.2.1 .1 .2 Session proceeding 

If an II Progress message with Progress reason set to Call progressing and containing an SCC AS PSI DN is received at 
the ICS UE while the II session identified by a valid Call-ID (see subclause 7.2.2.1.4) is in the "trying" state, the II 
session shall transit to the "proceeding" state. If an an unreliable transport-layer connection between the ICS UE and the 
SCC AS is used timer E shall be stopped and cleared. 

If an unreliable transport-layer connection between the ICS UE and the SCC AS is used, when the session enters the 
"proceeding" state the ICS UE sets the timer E to fire in T2 seconds. If timer E fires while the session is in the 
"proceeding" state, the original II Invite message (with the same sequence number) is retransmitted and the timer E is 
reset to a value of T2 seconds. This process continues so that retransmissions of the original II Invite message occur 
every T2 seconds. 

If timer F fires while the session is in the "proceeding" state, the session establishment has failed, and the ICS UE clears 
the call, as described in subclause 6.2.3. In addition, if an unreliable transport-layer connection between the ICS UE and 
the SCC AS is used the, the ICS UE disables timer E. 

Upon receiving the II Progress message with Progress reason set to Call progressing from the SCC AS, the ICS UE 
initiates the setting up of the CS bearer connection toward the SCC AS by sending a SETUP message to the MSC 
Server as specified in subclause 6.2.1.2.1. 

NOTE: The request to set up the CS bearer connection arriving at the SCC AS indicates that the II Progress 
message with Progress reason set to Call progressing has been received by the UE. Subsequently, the 
SCC AS can progress the II session toward the far end by sending a SIP INVITE request to the far end. 

7.5.3.2.1 .1 .3 Alerting indication 

If an II Progress message with Progress reason set to Ringing is received while the II session identified by a valid Call- 
ID (see subclause 7.2.2.1.4) is in the "proceeding" state, the II session shall transit to the "alerted" state. 

If an unreliable transport-layer connection between the ICS UE and the SCC AS is used, when the session enters the 
"alerted" state the ICS UE sets timer E to fire in T2 seconds. If timer E fires while the session is in the "alerted" state, 
the original II Invite message (with the same sequence number) is retransmitted and the timer E is reset to a value of T2 
seconds. This process continues so that retransmissions of the original II Invite request occur every T2 seconds. 

If timer F fires while the session is in the "alerted" state, the session establishment has failed, and the ICS UE clears the 
call, as described in subclause 6.2.3. In addition, if an unreliable transport-layer connection between the ICS UE and the 
SCC AS is used, the ICS UE disables timer E. 

If the ICS UE receives an II Progress message with Progress reason set to Ringing, the ICS UE may begin a locally- 
generated alerting procedure. 

7.5.3.2.1.1.4 Session connected 

If an II Success message is received from the SCC AS while the II session at the UE is either in the "proceeding" state 
or "alerted" state, the II session shall transit to the "confirmed" state (i.e., the II session has been established) and the 
timer F is disabled. The ICS UE shall stop any locally generated alerting procedures (if applied). 

If an unreliable transport-layer connection between the ICS UE and the SCC AS was used, the timer E is disabled, 
hence the ICS UE stops retransmitting the II Invite message. In addition, the ICS UE discards any subsequent II 
Success message, if it is received over the unreliable transport-layer connection. 

7.5.3.2.1 .2 Procedure at SCC AS 

7.5.3.2.1.2.1 Session request 

Upon receiving an II Invite message from the ICS UE over the II interface, the session at the SCC AS shall transit to 
the "initiated" state. Once in the "initiated" state, the SCC AS shall immediately respond by sending an II Progress 
message with Progress reason set to Call progressing to the UE and the session enters the "progressing" state. The II 
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Progress message with Progress reason set to Call progressing shall contain the II information elements as specified in 
subclause 6.2.1.3.1. 

NOTE: The receipt of the II Progress message with Progress reason set to Call progressing at the UE, will trigger 
the UE to set up a CS bearer connection toward the SCC AS by sending a SETUP message to the MSC 
Server as specified in subclause 6.2.1.2.1. 

7.5.3.2.1.2.2 Session progressing 

If the SCC AS receives a retransmitted II Invite message from the ICS UE, while the II session is in the "progressing" 
state, the SCC AS shall retransmit the previously sent II Progress message with Progress reason set to Call progressing 
to the ICS UE. 

NOTE: The SCC AS receives a retransmitted II Invite message only if the transport-layer connection between the 
ICS UE and the SCC AS is an unreliable transport-layer connection. While the II session is in the 
"progressing" state, the SCC AS may send to the ICS UE either an II Progress message with Progress 
reason set to Ringing, an II Success message indicating that the II session has been accepted, or a new II 
Progress response with Progress reason set to Call progressing. 

If timer F fires while the session is in the "progressing" state, the II session establishment has failed, and the SCC AS 
clears the II session, as described in subclause 6.2.3. 

7.5.3.2.1.2.3 Alerting indication 

If the SCC AS sends an II Progress message with Progress reason set to Ringing to the ICS UE, the session state at the 
SCC AS shall transit to the "alerting" state. 

If the SCC AS receives a retransmitted II Invite message from the ICS UE, while the session is in the "alerting" state, 
the SCC AS shall retransmit the previously sent II Progress message with Progress reason set to Ringing to the ICS UE. 

NOTE: The SCC AS receives a retransmitted II Invite message only if the transport-layer connection between the 
UE and the SCC AS is an unreliable transport-layer connection. 

If timer F fires while the session is in the "alerting" state, the session establishment has failed, and the SCC AS clears 
the session, as described in subclause 6.2.3. 

7.5.3.2.1.2.4 Session connected 

If the SCC AS sends an II Success message to the ICS UE indicating that the session has been accepted, the session 
state at the SCC AS shall transit to the "confirmed" state. 

If an unreliable transport-layer connection between the UE and the SCC AS is used, when the session enters the 
"confirmed" state the SCC AS sets timer G to fire in (n*T2) seconds. For reliable transport-layer connection timer G is 
not used. If a retransmitted II Invite message is received while the timer G is running, the timer G is reset to fire in 
(n*T2) seconds, and the II Success message is retransmitted. The firing of the timer G indicates that the ICS UE has 
received the II Success message and the ICS UE has stopped the retransmission of the II Invite message. 

If timer G fires while the session is in the "confirmed" state, the timer F is disabled. 

If timer F fires while the session is in the "proceeding" state, the session establishment has failed, and the SCC AS 
resets timer G and clears the session, as described in subclause 6.2.3. 

7.5.3.2.2 UE-terminating case 

7.5.3.2.2.1 Procedure at ICS UE 

7.5.3.2.2.1.1 Session request 

Upon receiving an II Invite message from the SCC AS over the II interface, the session at the ICS UE shall transit to 
the "initiated" state. Once in the "initiated" state, the ICS UE shall immediately respond by sending an II Progress 
message with Progress reason set to Call progressing to the SCC AS and enter the "progressing" state. The II Progress 
message with Progress reason set to Call progressing shall contain the 11 information elements as specified in 
subclause 6.2.1.2.2. 
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NOTE: The receipt of the II Invite message at the UE will trigger the UE to set up a CS bearer connection toward 
the sec AS by sending a SETUP message to the MSC Server as specified in subclause 6.2.1.2.1. 

When the session enters the "initiated" state, the ICS UE also sets timer F to fire in T3 seconds. 

7.5.3.2.2.1.2 Session progressing 

If the ICS UE receives a retransmitted II Invite message from the SCC AS, while the II session is in the "progressing" 
state, the ICS UE shall retransmits the previously sent II Progress message with Progress reason set to Call progressing 
to the UE. 

NOTE: The UE receives a retransmitted II Invite message only if the transport-layer connection between the UE 
and the SCC AS is an unreliable transport-layer connection. 

While the session is in the "progressing" state, the ICS UE may send to the SCC AS with the same Call-ID, either an II 
Progress message with Progress reason set to Ringing, an II Success message indicating that the call has been accepted, 
or a new II Progress message with Progress reason set to Call progressing. 

If timer F fires while the session is in the "progressing" state, the session establishment has failed, and the ICS UE 
clears the call, as described in subclause 6.2.3. 

7.5.3.2.2.1.3 Alerting indication 

If the ICS UE sends an II Progress message with Progress reason set to Ringing, the session state at the ICS UE shall 
transit to the "alerting" state. 

If the ICS UE receives a retransmitted II Invite message from the SCC AS with the same Call-ID, while the session is 
in the "alerting" state, the ICS UE shall retransmit the previously sent II Progress message with Progress reason set to 
Ringing to the SCC AS. 

NOTE: The UE receive a retransmitted II Invite message only if the transport-layer connection between the UE 
and the SCC AS is an unreliable transport-layer connection. 

If timer F fires while the session is in the "alerting" state, the session establishment has failed, and the UE clears the 
session, as described in subclause 6.2.3. 

7.5.3.2.2.1.4 Session connected 

If the ICS UE sends an II Success message indicating that the session has been accepted, the session state at the UE 
transits to the "confirmed" state. 

If an unreliable transport-layer connection between the UE and the SCC AS is used, the ICS UE sets timer G to fire in 
(n*T2) seconds. For reliable transport-layer connection timer G is not used. If an II Invite message is received while the 
timer G is running, the timer G is reset to (n*T2) seconds, and the II Success message is retransmitted. The firing of the 
timer G indicates that the SCC AS has received the Success message and has stopped the retransmission of the II Invite 

message. 

If timer G fires while the session is in the "confirmed" state, the timer F is disabled. 

If timer F fires while the session is in the "confirmed" state, the session establishment has failed, and the ICS UE clears 
the session, as described in subclause 6.2.3. 

7.5.3.2.2.2 Procedure at SCC AS 

7.5.3.2.2.2.1 Session request 

The SCC AS initiates a session establishment procedure by sending an II Invite message to the UE across the II 
interface. The II Invite message shall contain the II information elements as specified in subclause 6.2.1.3.2. Following 
the transmission of the II Invite message the session shall transit to the "trying" state. When the session enters the 
"trying" state, the SCC AS sets timer F to fire in T3 seconds. 

If an unreliable transport-layer connection between the UE and the SCC AS is used, the SCC AS sets timer E to fire in 
Tl seconds. For reliable transport-layer connection timer E is not used. If timer E fires while the session is still in the 
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"trying" state, the original II Invite message (with the same sequence number) is retransmitted and the timer E is reset 
to value of MIN(2*T1, T2). If the timer E fires again, the original II Invite message (with the same Call-ID and 
sequence number) is retransmitted again and the timer E is reset to a MIN (4*TI, T2). This process continues so that 
retransmissions occur with an exponentially increasing interval that caps at T2. 

If timer F fires while the session is still in the "trying" state, the session establishment has failed, and the SCC AS clears 
the session, as described in subclause 6.2.3. In addition, if an unreliable transport-layer connection between the UE and 
the SCC AS is used, the SCC AS disables timer E. 

7.5.3.2.2.2.2 Call proceeding 

If an II Progress message with Progress reason set to Call progressing is received at the SCC AS while the session is in 
the "trying" state, the session shall transit to the "proceeding" state. 

If an unreliable transport-layer connection between the UE and the SCC AS is used, when the session enters the 
"proceeding" state the SCC AS sets timer E to fire in T2 seconds. If timer E fires while the session is in the 
"proceeding" state, the original II Invite message (with the same sequence number) is retransmitted and the timer E is 
reset to a value of T2 seconds. This process continues so that retransmissions of the original II Invite message occur 
every T2 seconds. 

If timer F fires while the session is in the "proceeding" state, the session establishment has failed, and the SCC AS 
clears the session, as described in subclause 6.2.3. In addition, if an unreliable transport-layer connection between the 
UE and the SCC AS is used, the SCC AS disables timer E. 

NOTE: The request to set up the CS bearer connection arriving at the SCC AS indicates that the II Invite message 
has been received by the UE. 

7.5.3.2.2.2.3 Alerting indication 

If an II Progress message with Progress reason set to Ringing is received while the session is in the "proceeding" state, 
the session shall transit to the "alerted" state. 

If an unreliable transport-layer connection between the UE and the SCC AS is used, when the session enters the 
"alerted" state the SCC AS sets timer E to fire in T2 seconds. If timer E fires while the session is in the "alerted" state, 
the original II Invite message (with the same sequence number) is retransmitted and the timer E is reset to a value of T2 
seconds. This process continues so that retransmissions of the original II Invite message occur every T2 seconds. 

If timer F fires while the session is in the "alerted" state, the session establishment has failed, and the SCC AS clears the 
session, as described in subclause 6.2.3. In addition, if an unreliable transport-layer connection between the UE and the 
SCC AS is used, the SCC AS disables timer E. 

7.5.3.2.2.2.4 Session connected 

If an II Success message is received from the ICS UE while the II session at the SCC AS is either in the "proceeding" 
state or "alerted" state, the II session shall transit to the "confirmed" state (i.e., the II session has been established) and 
the timer F is disabled. 

If an unreliable transport-layer connection between the UE and the SCC AS was used, the timer E is disabled, hence the 
SCC AS stops retransmitting the II Invite message. In addition, the SCC AS discards any subsequent II Success 
message, if it is received over the unreliable transport-layer connection. 

7.5.3.3 11 service control signalling release 

7.5.3.3.1 Initiating release of II service control signalling 

The ICS UE or the SCC AS can release a II service control signalling session at any time irrespective of its state. The 
ICS UE or the SCC AS releases the II service control signalling session by sending an II Bye message across the II 
interface. The II Bye message shall contain the II information elements as specified in subclause 6.2.3. 

If an II Success message is received while the II service control signalling session is in the "release-requested" state, it 
transits to the "null" state (i.e., the II service control signalling session has been released). 
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7.5.3.3.2 Responding to release of 11 service control signalling 

If either the ICS UE or the SCC AS receives an II Bye message across the II interface, the state of the II service 
control signalling session at the recipient side of the II Bye message (i.e. either at the ICS UE or the SCC AS) shall 
transit to the "release-indication" state. If there are more II service control signalling sessions, once in the "release- 
indication" state, the recipient side of the II Bye message shall immediately respond by sending an II Success message. 
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Annex A (normative): 

Data structure associating keys with values 

A.1 General 

A UE and a SCC AS maintain a hash table associating keys with values. The keys shall be hashes resulting of applying 
a hashing function to string values. SHA-1 shall be used as the hash algorithm. 

A.2 Associating keys with values 

The UE and the SCC AS shall have one or more tables associating keys with values. 

A.2.1 Associating keys with public user identities 

The UE and the SCC AS shall create a hash table of the SIP URIs present in the P-Associated-URI header field. If the 
UE and SCC AS also subscriber to the Reg-Event package as documented in 3GPP TS 24.229 [12] the UE and SCC AS 
shall create a hash table of the GRUU's for URIs received in the Reg-Event package in addition to those received in the 
P-Associated-URI header field. 

NOTE: The 200 (OK) response to a incoming REGISTER request includes a P-Associated-URI header field and 
is delivered to the SCC AS as part of the third party registration procedures documented in 

3GPPTS 24.229 [12]. 
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